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10 BACKGROUND OF THE INVENTION 

Field of the Invention 

The present invention relates generally to 
executing computer software programs generated by 
15 different compilers, and in particular to a method for 
enabling a first computer software program using a 
first binary specification to employ functionality of a 
second computer software program using a second binary 
specification . 

20 

Description of Related Art 

Many computer software programs, which are created 
in different programming languages, have to communicate 
with each other. For example, a first computer 

25 software program, sometimes called the first software 
program, created in a first computer programming 
language is able to provide tables. The first software 
program calls a second software program created in a 
second programming language, which is able to calculate 

3 0 figures that are needed in the table to be produced by 
the first software program. (As those of skill in the 
art will appreciate, when it is stated that a software 
program performs an action, this means that upon 
execution of the software program on a processor, the 

35 system including the processor performs the action in 
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response to execution of an instruction or instructions 
in the software program.) 

Since the two software programs are written in 
different languages, the two software programs have 
5 different binary specifications. The second software 
program cannot be successfully called by the first 
software program because the different binary 
specifications prevents the second software program 
from correctly executing the call from the first 

10 software program. 

In this example, the different binary 
specifications result from different computer 
programming languages. However, binary specifications 
for the same computer programming language can be 

15 different based upon the differences in the compilers 
for the same programming language . 

The prior art solution to this problem was to 
provide transformer modules for each required 
transformation route, for example from a certain first 

20 binary specification to a certain second binary 

specification. Since in modern computer applications, 
a certain software program may call many different 
software programs, the computer system requires a 
voluminous library of transformer modules. This 

25 extensive library needs significant storage space and 
regular maintenance, since for every new binary 
specification, which shall be accessible, a full new 
set of transformer modules must be provided to each of 
the other binary specifications, in addition to the 

30 existing transformer modules. However, most of these 
transformer modules are not used frequently, so that 
their storage is not efficient. 

Furthermore, these prior art transformer modules 
extend to the full functionality of the software 

35 program to be translated from one binary specification 
to another. Due to the regularly wide functionality of 
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software programs, known transformer modules are rather 
voluminous and require, when they are activated, a 
significant amount of working memory and processor time 
from the computer system on which they are executed. 
5 Furthermore, the complete translation of a software 
program is burdensome and time consuming, although it 
is in most cases unnecessary for the specific task to 
be accomplished. 

10 SUMMARY OF THE INVENTION 

According to one embodiment of the present 
invention, an efficient method is provided to enable a 
first software program to employ certain 

functionalities of a second software program, where the 
15 first and the second software program use different 
binary specifications, i.e., the first and second 
software programs are in different execution 
environments . 

In one embodiment, a method for enabling a first 

2 0 software program using a first binary specification in 

a first execution environment to employ a limited 
functionality of a second software program using a 
second binary specification in a second execution 
environment first creates a bridge in the first 
25 execution environment. Using the bridge, a proxy 

wrapping an interface to the limited functionality of 
the second software program in the second execution 
environment is created in the first execution 
environment . 

3 0 In another embodiment, a method, dynamically 

implemented by a process in a first execution 
environment generates a binary specification object for 
the first execution environment. A binary 
specification object for a second execution environment 
35 is also generated. Next the process generates a bridge 
object for mapping objects from the second execution 
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environment to the first execution environment. For 
example, using the bridge object, the process generates 
a proxy wrapping an interface in the second execution 
environment . The interface in the second execution 
5 environment is used to access limited functionality in 
the second execution environment . 

In one embodiment, to use the limited 
functionality in the second execution environment in a 
first execution environment, a process executing in the 

10 first execution environment calls a method in a proxy 
interface in the first execution environment. In 
response to the call, the proxy interface converts the 
method to a corresponding method call for execution in 
the second execution environment. A method type 

15 description is used to convert parameters from the 
first execution environment to the second execution 
environment, and in one embodiment, a parameter type 
description for the method is used. 

The proxy interface dispatches the corresponding 

2 0 method call for execution in the second execution 

environment to the second execution environment by the 
proxy interface. In response to the corresponding 
method call in the second execution environment, the 
method providing the limited functionality is executed 
25 and the results of the execution are returned to the 
proxy interface. Using a type description, the 
returned results from the second execution environment 
are converted to the first execution environment and 
returned to the calling process. In one embodiment, 

3 0 the second execution environment is a C++ programming 

language execution environment. 

In another embodiment of this invention, a 
computer program product comprises computer program 
code for a method for enabling a first software program 
35 using a first binary specification in a first execution 
environment to employ a limited functionality of a 
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second software program using a second binary 
specification in a second execution environment, the 
method comprising: 

creating a bridge in said first execution 
5 environment ; and 

creating, in said first execution environment 
using said bridge, a proxy wrapping an interface 
to said limited functionality of said second 
software program in said second execution 
10 environment. 

In another embodiment, a computer program product 
comprises computer program code for a method for using 
functionality in a second execution environment in a 
first execution environment, the method comprising: 
15 calling a method in a proxy interface in said 

first execution environment; and 

converting said method call by said proxy 
interface to a corresponding method call for 
execution in said second execution environment. 
20 One embodiment of the present invention includes a 

computer storage medium having stored therein a 
structure comprising a binary specification for an 
execution environment that in turn includes a simple 
common identity structure. Optionally, the binary 
25 specification also includes an extended environment 
structure. In one embodiment, the simple common 
identity structure includes: a type name, a context, a 
pointer to the extended environment structure, and 
methods acquire, release and dispose. 

30 

BRIEF DESCRIPTION OF THE DRAWINGS 

Fig. 1A is a high level representation of a first 
embodiment of the present invention. 

Fig. IB is a high level representation of a second 
3 5 embodiment of the present invention. 
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Fig. 1C is a more detailed representation of the 
first embodiment of the present invention. 

Figs. 2A and 2B are one embodiment of a binary 
representation of an environment according to one 
5 embodiment of the present invention. 

Figs. 3A and 3B are one embodiment of the binary- 
specification structure of Fig. 2B. 

Fig. 4 is a sequence diagram illustrating one 
embodiment of making a proxy interface of the present 
10 invention, and one embodiment of using the proxy 
interface of the present invention. 

Fig. 5 is an example of a binary specification of 
the type representation in the UNO typelibrary 
according to one embodiment of the present invention. 
15 Fig. 6 is an illustration of stack configuration 

used in one embodiment of a C++ environment. 

Fig. 7A is an illustration of a virtual table in 
one embodiment of the present invention. 

Fig. 7B is an illustration of assembler code used 
2 0 to generate an index to a slot in the virtual table of 
Fig. 6. 

Fig. 8 is a process flow diagram for one 
embodiment of a method performed by a C++ proxy 
wrapping a UNO interface . 

2 5 Fig. 9 is a process flow diagram for one 

embodiment of a method mediate that is used by the 
method of Fig . 8 . 

Fig. 10 is a process flow diagram for one 
embodiment of a method Envl_to_Env2 with interface that 

3 0 is used by method mediate of Fig. 9. 

Fig. 11 is a process flow diagram for one 
embodiment of a method performed by a UNO proxy 
wrapping a C++ interface . 

Fig. 12 is a process flow diagram for one 
3 5 embodiment of a method Env2_to_Envl with interface that 
used by the method of Fig. 11. 
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Figs. 13A and 13B are an example of mapping an 
interface from a UNO environment to a C++ UNO 
environment according to one embodiment of the present 
invention . 

5 Fig. 14 is an example of freeing a C++ UNO 

interface proxy and revoking the proxy of the 
appropriate environment according to one embodiment of 
the present invention. 

Fig. 15 is an example of a C++ implementation of a 
10 C++ UNO proxy according to one embodiment of the 
present invention. 

Figs. 16A and 16B are an example of a C 
implementation of freeing a UNO interface proxy and 
functions acquire/release according to one embodiment 
15 of the present invention. 

Figs. 17A and 17B are an example of mapping an 
interface from a C++ UNO environment to a UNO 
environment according to one embodiment of the present 
invention . 

20 Fig. 18 is an example of a C++ implementation of a 

UNO proxy according to one embodiment of the present 
invention . 

Fig. 19 is an example of various constructors of a 
mapping and a bridge and of a free function of a bridge 
25 according to one embodiment of the present invention. 

Fig. 2 0 is an example of an implementation of 
functions acquire and release for a bridge according to 
one embodiment of the present invention. 

Fig. 21 is an example of an implementation to 
3 0 create a mapping between to environments according to 
one embodiment of the present invention. 

Figs. 22A and 22B are an example of an 
implementation to create the static part of an object 
identifier according to one embodiment of the present 
35 invention. 
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Fig. 2 3 is an example of an implementation to 
create an object identifier according to one embodiment 
of the present invention. 

Fig. 24 is an example of an implementation of 
5 methods acquire/release in a C++ UNO environment 

according to one embodiment of the present invention. 

In the Figures and the following Detailed 
Description, elements with the same reference numeral 
are the same element or a similar element. Also, the 
10 first digit of a reference numeral for an element 
indicates the figure in which that element first 
appeared . 



DETAILED DESCRIPTION 

15 According to one embodiment of the present 

invention, a computing system 100 includes a 
service 111, which is part of a first computer software 
program 110 executing within a first execution 
environment 120. Service 111 issues a call 112 to a 

2 0 service 161 of a second computer software program 160 
executing within a second execution environment 150 
that is different from first execution environment 120. 
For example, service 111, in one embodiment, is a part 
of a word processing program that issues a call to a 

25 calculator, which is service 161, of a spreadsheet 

program, where the word processing program is written 
in a Visual Basic computer programming language, and 
the calculator is written in the C programming 
language . 

30 Unlike the prior art in which calls to a different 

execution environment with a different binary- 
specification could not be handled in most cases, and 
in a limited number of cases could be handled by 
marshalling the call into a specific predefined byte 

35 stream (for example the CORBA byte stream) for passing 
to the different execution environment, call 112 from 
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first execution environment 120 with a first binary 
specification is directed to a proxy 130 in a 
bridge 140. Proxy 130 converts any parameters in the 
call to parameters for second execution environment 150 
5 using a type description that is described more 

completely below, and then dispatches a call 170, with 
the converted parameters, to service 161 in second 
execution environment 150. Call 170 corresponds to 
call 112 in first execution environment 120. 

10 In response to call 170 from proxy 130, 

service 161 performs the action requested and returns 
the result to proxy 130. Proxy 130 converts the result 
and any parameters returned from second execution 
environment 150 to first execution environment 120. 

15 The converted results are in turn provided to 
service 111. 

Hence, according to one embodiment of the present 
invention, a first service, sometimes called a 
component or an object, with a first binary 

20 specification in a first execution environment utilizes 
a second service sometimes called a component or an 
object, in a second execution environment with a second 
binary specification that is different from the first 
binary specification. This greatly extends and 

25 facilitates providing an application with a broad range 
of capabilities without having to port the application 
and/or all of the capabilities to the binary 
specification of each execution environment in which 
the application may run. In addition, this embodiment 

30 facilitates providing a particular functionality to an 
application that is executed in an execution 
environment that does not, and perhaps cannot, support 
that particular functionality. 

In the embodiment of Figure 1A, proxy 13 0 is 

35 instantiated by bridge 140 that is in first execution 
environment 12 0 and proxy 13 0 communicates directly 
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with service 161 that is in second execution 
environment 150. However, in another embodiment, 
proxy 130A in response to a call 112 from service 111 
of software program 110 issues a call 131 to an 
5 intermediary proxy 185 in execution environment 180 
that is different from both execution environment 120 
and execution environment 150, in this example. 

Intermediary proxy 13 OA converts the call from the 
first binary specification to the binary specification 

10 for execution environment 180 and dispatches a call 131 
to intermediary proxy 185. Intermediary proxy 185 
converts the call from the binary specification of 
execution environment 180 to the binary specification 
of execution environment 150 and then dispatches 

15 call 186 to service 161. The response from service 161 
is returned to intermediary proxy 185 that converts the 
response to binary specification of execution 
environment 180, and in turn transmits the converted 
response to proxy 130A. Proxy 13 OA converts the 

2 0 response from the binary specification for execution 
environment 180 to the binary specification for 
execution environment 120 and returns the result to 
service 111 of software program 110. 

To reduce the number of bridges, normally only 

25 bridges to intermediate environment 180, referred to 
herein as the binary UNO specification environment, 
exist. To make a bridge from a C programming language 
(C) execution environment to a C++ programming language 
(C++) execution environment, call traffic is delegated 

30 over two bridges 140A and 190. First bridge 140A is 
from the C execution environment to the binary UNO 
execution environment and then bridge 190 is from the 
binary UNO execution environment to the C++ execution 
environment. In this way, only (n -1) bridges are 

35 needed for n different environments instead of n* (n - 
l)/2 bridges, if a direct connection between 



-10- 



AsFiled 
P-4355 



environments is made as in Fig. 1A. Preferably each 
bridge can create proxy objects only from the 
description of an interface. This implies that the 
code may be generated at runtime. 
5 Returning to Figure 1A, as explained more 

completely below, a source environment object 103 and a 
destination environment object 104 are initially 
created using a runtime library, and optionally 
registered in an execution environment, e.g., execution 

10 environment 120. Each of objects 103 and 104 includes 
a binary specification structure for its respective 
execution environment. As explained more completely 
below, a binary specification structure, in one 
embodiment, provides common functions for each 

15 environment, and knows all proxies, sometimes called 
proxy interfaces, and their origins. Thus, an 
execution environment, through its binary specification 
structure, knows each wrapped interface, i.e., proxy, 
running in execution environment and the origin of each 

2 0 of these wrapped interfaces. 

After the objects 103 and 104 are created, a call 
is made by service 111 that results in a search for a 
shared library that is activated as a bridge for the 
two execution environments. Each bridge, e.g., 
25 bridge 140, is implemented in a separate shared 

library. In one embodiment, the name of the shared 
library is a connection of two environment names with 
an underscore ('__') between the names. 

Next a call is made by service 111 to map an 

3 0 interface of the source environment. Mapping is the 

direct way to publish an interface in another 
environment . That means an interface is mapped from a 
source environment 150 to a destination environment 12 0 
so that methods may be invoked on a mapped interface, 
35 i.e., proxy 130, in destination environment 120, which, 
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in turn, are delegated to the originating interface in 
the source environment . 

Mapping an interface from an environment 15 0 to an 
environment 120 requires several operations that are 
5 described more completely below with respect to 
Figure 4. However, briefly, a call is made to 
bridge 14 0 to map a particular interface for 
service 161 in source execution environment 150 to 
destination execution environment 120. If a proxy 

10 already exists for this mapping, a handle to the proxy 
is returned to service 111. Alternatively, as 
explained below, bridge 140 creates proxy 13 0, and 
returns a handle to service 111 so that subsequent 
calls to the interface for service 161 are directed to 

15 proxy 13 0. 

Hence, as used herein, a bridge 140 in a first 
environment 12 0 is defined to be a software module that 
upon execution initially creates a proxy object 13 0 in 
first environment 12 0 for one computer programming 

2 0 language and hardware platform so that an actual 
object 161, sometimes called real object 161, 
represented by proxy 13 0, is available from a second 
environment 150. Proxy object 130 looks like and is an 
object implemented in first environment 120, and so 

25 proxy object 13 0 can be transparently used. Proxy 

object 130 delegates calls to real object 161 in second 
environment 150. 

In one embodiment, real object 161 in second 
environment 150 is implemented in the C programming 

30 language (C) and real object 161 is accessed from a C++ 
programming language (C++) environment. In this case, 
bridge 14 0 is from a C++ environment to a C 
environment. Remember that C++ is incompatible between 
different compilers and different switches. Bridge 140 

35 creates a C++ proxy object 130 in first 

environment 12 0, which delegates calls to real 
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object 161 implemented in C. Sometimes a bridge is 
called language binding, but this description is not 
exact, because bridges also connect object models in 
another embodiment of the present invention. 
5 The particular configuration of computing 

system 100 is not essential to this invention. 
Execution environments 12 0 and 150, in one embodiment, 
are included within the same computer. 

In another embodiment, execution environment 12 0 

10 is in a client system and execution environment 150 is 
in a server system. In this embodiment, the client 
system can be a mobile telephone, a two-way pager, a 
portable computer, a workstation, or perhaps a personal 
computer. The client and server can be interconnected 

15 by a local area network, a wide area network, or the 
Internet. As explained more completely below, the 
dynamic dispatch functionality of this invention is 
independent of the network protocol and the network 
architecture. In yet another embodiment, execution 

20 environment 120 is in a first computer and execution 

environment 150 is in a second computer where the first 
and second computers are in a peer-to-peer network. 

Figure 1C is an example of a user device 102 that 
is executing service 111 of application 110 from a 

25 volatile memory 122 on CPU 101. Application 110 can be 
any application, or an application in a suite of 
applications that can include for example a word 
processing application, a spreadsheet application, a 
database application, a graphics and drawing 

30 application, an e-mail application, a contacts manager 
application, a schedule application, and a presentation 
application. One office application package suitable 
for use with this embodiment of the invention, is the 
STAROFFICE Application Suite available from Sun 

3 5 Microsystems, 901 San Antonio Road, Palo Alto, CA. 

(STAROFFICE is a trademark of Sun Microsystems, Inc.) 
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The user has access to the functionality of service 161 
even thought the execution environment for computer 155 
is different from the execution environment of user 
device 102 and even in situations where in addition 
5 user device 102 has neither the memory capacity nor the 
processing power to execute service 161. 

In the embodiment of Figure 1C, a runtime 
library 108 is initially stored in a non-volatile 
memory 121 and a part or all of runtime library 10 8 is 

10 moved to volatile memory 122 to generate source 
environment object 103, destination environment 
object 104 and bridge 14 0. In one embodiment, 
bridge 14 0 includes a shared library and is the same 
library as runtime library 108. 

15 In this embodiment, when proxy 13 0 receives a 

method call from service 111, proxy 130 dispatches the 
call to service 161 via I/O interface 122 that is 
connected to network interface 183 of computer 155 via 
networks 105 and 106. 

2 0 Those skilled in the art will readily understand 

that the operations and actions described herein 
represent actions performed by a CPU of a computer in 
accordance with computer instructions provided by a 
computer program. Therefore, bridge 14 0, proxy 13 0, 
25 source environment object 103, and destination 

environment object 104 may be implemented by a computer 
program causing the CPU of the computer to carry out 
instructions representing the individual operations or 
actions as described herein. The computer instructions 

3 0 can also be stored on a computer -readable medium, or 

they can be embodied in any computer-readable medium 
such as any communications link, like a transmission 
link to a LAN, a link to the internet, or the like. 

Thus, all or part of the present invention can be 
35 implemented by a computer program comprising computer 
program code or application code. This application 
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code or computer program code may be embodied in any 
form of a computer program product. A computer program 
product comprises a medium configured to store or 
transport this computer-readable code, or in which this 
computer- readable code may be embedded. Some examples 
of computer program products are CD-ROM discs, ROM 
cards, floppy discs, magnetic tapes, computer hard 
drives, servers on a network, and carrier waves. The 
computer program product may also comprise signals, 
which do not use carrier waves, such as digital signals 
transmitted over a network (including the Internet) 
without the use of a carrier wave. 

The storage medium including runtime library 108 
may belong to user device 102 itself. However, the 
storage medium also may be removed from user 
device 102. The only requirement is that the runtime 
library is accessible by user device 102 so that the 
computer code corresponding to the environment objects, 
bridge and proxy can be executed by user device 102. 
Moreover, runtime library 108 can be downloaded from 
another computer coupled to user device 102 via a 
network. Also, user device 102, as explained above, 
can also be a server computer and so the configuration 
of Figure 1C is illustrative only and is not intended 
to limit the invention to the specific embodiment 
shown . 

Herein, a computer memory refers to a volatile 
memory, a non- volatile memory, or a combination of the 
two in any one of these devices. Similarly, a computer 
input unit and a display unit refer to the features 
providing the required functionality to input the 
information described herein, and to display the 
information described herein, respectively, in any one 
of the aforementioned or equivalent devices. 

As used herein, software programs are compiled 
executable programs. Software programs are initially 
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written in a programming language, for example, C, C++ 
or JAVA or an object model like CORBA or UNO . They are 
compiled with compilers corresponding to the 
programming language. However, for each programming 
language several compilers may be available. The 
binary specification in which a software program is 
able to communicate with other software programs 
depends on both, the programming language and the 
compiler. This communication language of a software 
program is the language referred herein as the binary 
specification used by a software program. 

As used herein, an execution environment, such as 
execution environments 120 and 150, contains all 
objects, which have the same binary specification and 
which lie in the same process address space. The 
execution environment, sometimes called environment, 
herein, is specific for a computer programming language 
and for a compiler for that computer programming 
language. For example, an object resides in the "msci" 
execution environment, if the object is implemented 
with a software program written in the C++ computer 
programming language, and the software program is 
compiled with the MICROSOFT Visual C++ compiler. 
(MICROSOFT is a trademark of Microsoft Corp. of 
Redmond, WA) An example of a binary specification for 
one sample execution environment is presented below in 
conjunction with the description of Table 1. 

To assist in the understanding of this invention, 
examples of a binary specification for an environment, 
and types, type libraries, and a type repository are 
first considered, and then embodiments to make and use 
the present invention are described. 
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Binary Specification for an Execution Environment . 

The function of a binary specification for an 
execution environment is to identify the execution 
5 environment, and optionally to provide functionality 
like interface registration. In one embodiment, the 
structure of a binary specification for an execution 
environment is split into a simple common identity 
structure 220 (See Fig. 2A) that is easily implemented 

10 for bridges that handle object identity issues. An 
optional structure 225 may be included to support 
optional functionality. In one embodiment, the 
optional functionality includes interface registration, 
acquiring/releasing in interfaces of the environment, 

15 and obtaining an object identifier for an interface. 

Table 1 is an example of a simple common identity 
structure 220 (Fig. 2) of a binary specif icaiton for an 
execution environment called uno_enviroment . 

20 TABLE 1.: One Embodiment of a Simple Common Identity 
Structure for a Binary Specification of an Execution 
Environment 



typedef struct _uno_Environment 



uno_Ext Environment * pExtEnv; 

void (SAL_CALL * acquire) ( uno_Environment * pEnv ) 
void (SAL_CALL * release) ( uno_Environment * pEnv ) 
void ( SAL_CALL * dispose) ( uno_Environment * pEnv ) 
void (SAL_CALL * environment Disposing) ( 
uno_Environraent * pEnv ) ; 
} uno_Environment ; 



void 



void 



rtl__uString * 



pRe served; 
pTypeName ; 
pContext ; 
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Pointer pReserved in the UNO environment is 
reserved and so in this embodiment is set to zero. 
String pTypeName is a type name of the environment. 
Pointer pContext is a free context pointer that is used 
for specific classes of environments, e.g., a JAVA 
virtual machine pointer. (JAVA is a trademark of Sun 
Microsystems, Inc. of Palo Alto, CA. ) Pointer pExtEnv 
is a pointer to and extended environment (interface 
registration functionality) , if supported, and 
otherwise is set to zero. 

Method acquire acquires this environment, i.e., 
the environment defined by this structure. Parameter 
pEnv is this environment. Method release releases this 
environment and again parameter pEnv is this 
environment. Method dispose is explicitly called to 
dispose of this environment, e.g., to release all 
interfaces. Typically, this method is called before 
shutting down to prevent a runtime error. 

In this embodiment, method disposing is a 
disposing callback function pointer that can be set to 
be signaled before this environment is destroyed. This 
method is late initialized by a matching bridge and is 
not for public use 

Hence, in the embodiment, each simple common 
identity binary specification structure for an 
environment includes a type name of the environment; a 
free context pointer, a pointer to an extended 
environment that includes optional functionality, and 
methods to acquire, release and dispose of the 
environment. Structure 220 is stored in a memory 210 
of computer system 100. 
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TABLE 2 . : One Embodiment of an Extended Environment 
Structure for a Binary Specification of an Execution 
Environment 



typedef struct _uno_Ext Environment 
{ 

uno_Environment aBase; 

void (SAL_CALL * registerlnterf ace ) ( 

uno_ExtEnvironment * pEnv, 

void ** pplnterface, 

rtl_uString * pOId, 

typelib_Interf aceTypeDescript ion * pTypeDescr ) ; 
void (SAL_CALL * registerProxylnterf ace) ( 
uno_Ext Environment * pEnv, 
void ** ppProxy, 
uno_free Proxy Func freeProxy, 
rtl_uString * pOId, 

typelib_Interf aceTypeDescript ion * pTypeDescr ) ; 
void (SAL_CALL * revoke Interface) ( 

uno_Ext Environment * pEnv, void * plnterface ) ; 
void (SAL_CALL * getObj ectldent if ier) ( 

uno_Ext Environment * pEnv, 

rtl_uString ** ppOId, 

void * plnterface ) ; 
void (SAL_CALL * getRegisteredlnterf ace) ( 

uno_ExtEnvi ronment * pEnv, 

void ** pplnterface, 

rtl_uString * pOId, 

typelib_Interf aceTypeDescription * pTypeDescr ) ; 
void (SAL_CALL * getRegisteredlnterf aces) ( 

uno_Ext Environment * pEnv, 

void *** ppplnterf aces , 

sal_Int32 * pnLen, 

uno_memAlloc memAlloc ) ; 
void (SAL_CALL * computeObj ect Identifier) ( 
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uno_ExtEnvi ronment * pEnv, 

rtl_uString ** ppOId, void * plnterface ) ; 
void (SAL_CALL * acquirelnter f ace ) ( 

uno_Ext Environment * pEnv, void * plnterface ) ; 
void (SAL_CALL * releaselnterf ace) ( 

uno_ExtEnvironment * pEnv, void * plnterface ) ; 
} uno_Ext Envi ronment ; 



Table 2 is one embodiment of a binary 
specification of an UNO environment supporting 
interface registration. This binary specification 
5 inherits all members of a uno_Envi ronment as defined, 
for example, by Table 1 above. 

Method registerlnterface in Table 2 registers an 
interface of this environment . Parameter pEnv is this 
environment. Parameter pplnterface is an inout 
10 parameter of the interface to be registered. Parameter 
pOId is an object id of the interface to be registered, 
and parameter is a type description of interface to be 
registered. 

Method registerProxylnterface in Table 2 registers 
15 a proxy interface of this environment. The proxy 

interface can be reanimated and is freed explicitly by 
this environment. In this call, parameter pEnv is this 
environment. Parameter pplnterface is an inout 
parameter of interface to be registered. Parameter 
2 0 freeProxy represents a function to free this proxy 

object (See Table 3) . Parameter pOId is an object id 
of the interface to be registered, and parameter is a 
type description of interface to be registered. 

Method revokelnterface revokes an interface from 
25 this environment. Any interface that has been 

registered must be revoked via this method. In the 
call to this method, parameter pEnv is this 
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environment, and parameter plnterface is the interface 
to be revoked. 

Method getObjectldentif ier provides the object id 
of a given interface. In this method, parameter ppOId 
is the input and output object identifier (oid) , and 
parameter plnterface is the interface of the object. 

Method getRegisteredlnterface retrieves an 
interface identified by its object id and type from 
this environment. Interfaces are retrieved in the same 
order as they are registered. In this method, 
parameter pEnv is this environment. Parameter 
pplnterface is the inout parameter for the registered 
interface and is zero if none was found. Parameter 
pOId is the object id of the interface to be retrieved, 
and parameter pTypeDescr is a type description of 
interface to be retrieved. 

Method getRegisteredlnterfaces return all 
currently registered interfaces of this environment. 
The memory block allocated might be slightly larger 
than (*pnLen * sizeof (void *) ) . In this method, 
parameter pEnv is this environment. Parameter 
pplnterfaces is an output parameter that is a pointer 
to an array of interface pointers. Parameter pnLen is 
an output parameter to a length of the array of 
interface pointers, and parameter memAlloc represents a 
function for allocating memory that is passed back (See 
Table 4) . 

Methods computeObjectldentif ier, acquirelnterf ace 
and releaselnterface are late initialized by a matching 
bridge and are not for public use. Method 
computeObjectldentif ier computes an object id of the 
given interface, and is called by the environment 
implementation. Parameter pEnv is this environment, 
Parameter ppOId is an output parameter that is the 
computed id. Parameter plnterface is the given 
interface. Methods acquirelnterf ace and 
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releaselnterf ace are methods to acquire an interface, 
and release an interface respectively. The input 
parameters are defined the same as in method 
computeObj ectldentif ier . 

Table 3 is one embodiment of a generic function 
pointer declaration to free a proxy object, if an 
environment does not need the proxy object anymore. To 
use this function, the proxy object must register 
itself on the first call to method acquire () (See 
Table 1) call and revoke itself on the last call to 
method release () (See Table 1). This can happen 
several times because the environment caches proxy 
objects until the environment explicitly frees the 
proxy object by calling this function. In the call to 
this method, parameter pEnv the environment, and 
parameter pProxy is the proxy pointer. 

TABLE 3 . : One Embodiment of a Definition for 
Function FreeProxyFunc 



typedef void (SAL_CALL * uno_f ree Proxy Func) ( 

uno_ExtEnvironment * pEnv, void * pProxy ) ; 



Method memAlloc (Table 4) is a generic function 
pointer declaration to allocate memory. This method is 
used with method getRegisteredlnterf aces ( ) (Table 2). 
Parameter nBytes is the amount of memory in bytes. 
This method returns a pointer to the allocated memory. 

TABLE 4 . : One Embodiment of a Definition for 
Function memAlloc 



typedef void * ( SAL_CALL * uno_memAlloc) ( sal_ulnt32 
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nBytes ) ; 



An alternative embodiment of a structure 230 for a 
binary specification of an execution environment is 
presented in Figure 2B. In this embodiment, all the 
information including methods needed to manage 
registering and unregistering interfaces are includes 
in a single structure. Figures 3A and 3B are the 
information in one embodiment of structure 230. 
Alternatively, the information in Tables 2 and 3 could 
be combined into a single structure. 

To use environments, the environments are 
registered. An existing environment is obtaining by 
calling a method for getting the environment. For the 
example of Table 1, method uno_get Environment ( ) is 
used. A new environment is created by either 
implementing the new environment directly, or by using 
a simple default implementation, which is frequently 
also sufficient, by calling, in the given example, 
method uno_createDef aultEnvironment ( ) with the 
environment ' s name and the environment ' s acquire and 
release functions for interfaces. 

Within execution environments, type descriptions 
are used to map types between environments. A type 
description may exist or may be created at runtime. 
Each existing type in an execution environment is 
stored in a type repository along with the 
corresponding type description. The type descriptions 
are accessible through the full name of each type in 
the type repository, in one embodiment. For example, 
the full name of interface type "XInterface" may be 
"com. sun. star .XInterf ace" . The naming conventions used 
to access a type and/or a type description within the 
type repository are not an essential feature of this 
invention, and any suitable naming convention can be 
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utilized. In a type repository, the types and 
associated type descriptions are stored in any 
appropriate way. 

If the API (application program interface) of the 
type repository is a C programming language style, the 
type repository API is directly, that means via a 
binary representation, accessible from many binary 
specifications, and the type repository API is quickly 
transferable. Since the type description of each 
element may be used during the generic marshaling of a 
call, in one embodiment, C- style structures, which 
describe each type, are used. 

Figure 5 is an example of a binary specification 
50 0 of the type representation in the UNO typelibrary. 
The type library includes complete type descriptions 
for each existing IDL type. These type descriptions 
are organized in a hierarchical form, which represents 
the IDL module structure including a node for the type 
itself. Each type node has a binary type blob, which 
contains the complete type information. The structure 
of the type blob depends on the kind of the type. The 
first part is relevant for each type and the other 
parts depend on the type. For example, a structure has 
only an additional field section because it isn't 
possible to specify methods for structures. 

In this embodiment, the structure includes a 
header section; a constant pool section; a field 
section; and a reference section. A definition of the 
information is each section, as illustrated in Figure 5 
is given herein. 

Header section 

magic, type: sa.l_alnt.32 

a reserved field for internal use. 
size, type: sal__ulnt32 

represents the size of the blob in bytes. 
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minor, major version, type: sa.l_ulntl6 

two fields to specify a version number for 
the binary format . 
nHeaderFields , type: sal_ulntl6 
5 specifies the number of fields in the header 

section. This number is used for 
calculating the offset of the next 
section. 
typeSource, type: sal_ulntl6 
10 specifies in which language the type was 

defined, e.g. UNO IDL, CORBA IDL or 
Java . 

typed as s , type: sal_ulntl6 

specify the typeclass of the described type, 
15 e.g. interface or enum. 

name, type: sal^Jntl^ 

represents an index for a string item in the 
constant item pool which specifies the 
full qualified name of the type. 
2 0 Uik, type: sal_ulntl6 

represents an index for a Uik item in the 
constant item pool which contains the 
Uik information for an interface. This 
field is 0 if the type is not an 

2 5 interface. 

docu, type: sal__ulntl6 

represents an index for a string item in the 
constant item pool which contains the 
documentation of this type. 

3 0 filename, type sal_ulntl6 

represents an index for a string item in the 
constant item pool which specifies the 
name of the source file where the type 
is defined. 
3 5 nSuperTypes, type: sal_ulntl6 
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specifies the count of supertypes . This field 
is only relevant for structs, 
exceptions, services and interfaces. If 
nSuperTypes > 0 than the next section is 
an area with size nSuperTypes * 
sal_ulntl6, which represents indices for 
string items in the constant pool. 

Constant pool section 

The constant pool section consists of 
nConstantPoolCount entries of variable length and type. 
Each entry constists of three fields: 
size, type: sal_ulnt32 

specifies the size of the entry in bytes 
type tag, type: sal_ulntl6 

specifies the type of the data field, 
data, type; sal_ulnt8 

specifies the raw data of the entry with 
(size - sizeof (sal_ulnt32) - 
sizeof (sal_ulntl6) ) bytes. 

Field section 

The field section represents type information for 
struct or exception members, const types, enums, 
service members and attributes of interfaces. This 
section only exists if the field nFieldCount is greater 
than zero . 

nFieldCount, type: sal__ulntl6 

specifies the number of fields in the field 
section . 

nFieldEntries , type: sal_ulntl6 

specifies the number of fields for each entry 
in the field section. This number is 
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used for calculating the offsets in the 
field section. 
access, type: sal_ulntl6 

specifies the access of the field, e.g. 
readonly . 
name, type: sal_ulntl6 

represents an index for a string item in the 
constant item pool, which specifies the 
name of the field. 
typename, type: sal_ulntl6 

represents an index for a string item in the 
constant item pool, which specifies the 
full -qualified typename of the field. 
value, type: sal_ulntl6 

represents an index for an item in the 

constant item pool with the same type 
specified by typename which represents 
the value of the field, e.g., the 
initial enum value or the value of a 
constant. This field could be 0. 
docu, type: sal_ulntl6 

represents an index for a string item in the 
constant item pool, which contains the 
documentation of this field. 
filename, type: sal_ulntl6 

represents an index for a string item in the 
constant item pool, which specifies the 
name of the source file where the field 
is defined. This could be different 
from the filename in the header section, 
because constants could be defined in 
different source files. 



Method section 



The method section represents type information for 
interface methods. This section only exists if the 
5 field nMethodCount is greater than zero. 



nMethodCount, type; sal_ulntl6 

specifies the number of methods in the method 
section. 

10 nMethodEntries , type: sal_ulntl6 

specifies the number of fields for each entry 
in the method section. This number is 
used for calculating the offsets in the 
method section. 
15 nParameterEntries , type: sal_ulntl6 

specifies the number of fields for each entry 
in a parameter section. This number is 
used for calculating the offsets in the 
parameter section. 
2 0 size, type: sal__ulntl6 

specifies the size of the current method 
entry in bytes . 
mode, type: sal_ulntl6 

specifies the mode of the method, e.g., 

2 5 oneway . 

name, type: sal_ulntl6 

represents an index for a string item in the 
constant item pool, which specifies the 
name of the method. 
30 re turn type, type; sal_ulntl6 

represents an index for a string item in the 
constant item pool, which specifies the 
full -qualified typename of the 
returntype of the method. 

3 5 docu, type: sal__ulntl6 
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represents an index for a string item in the 
constant item pool, which contains the 
documentation of this method. 
nParamCount , type: sa.l_ulnt.16 

specifies the number of parameters for this 
method. If parameters exist, the 
parameter section follows this field, 
type, type: sal_ulntl6 

represents an index for a string item in the 
constant item pool, which specifies the 
full -qualified typename of the 
parameter. 
mode, type: sal_ulntl6 

specifies the mode of the method, e.g., in, 
out or inout . 
name, type: sal_ulntl6 

represents an index for a string item in the 
constant item pool, which specifies the 
name of the parameter. 
nExceptionCount, type: sal_ulntl6 

specifies the number of exceptions for this 
method. If exceptions exist the 
exception section follows this field. 
excpName 1 . . . n, type: sal_ulntl6 

represent indices for string items in the 

constant item pool, which specifies the 
full -qualified name of exceptions. 

Reference section 

The reference section represents type information 
for references in services. This section only exists 
if the field nRef erenceCount is greater than zero. 
n^eferenceCount, type; sal_ulntl6 

specifies the number of references for this 
type. 



nReferenceEntries, type: sal_ulntl6 

specifies the number of fields for each entry 
in the reference section. This number 
is used for calculating the offsets in 
the reference section. 
typename, type: sal_ulntl6 

represents an index for a string item in the 
constant item pool, which specifies the 
full -qualified typename of the 
reference . 
name, type: sal_ulntl6 

represents an index for a string item in the 
constant item pool, which specifies the 
name of the reference. 
docu r type: sal_ulntl6 

represents an index for a string item in the 
constant item pool, which contains the 
documentation of this reference, 
access, type: sal__ulntl6 

specifies the access of the reference, e.g. 
needs, observes or interface. 

In one embodiment of a type repository, all 
functions or type declarations have a prefix 
"typelib_" . In one embodiment of the type repository 
API, a function typelib_TypeDescription_newInterface is 
used to create an interface description. The 
descriptions of structures, unions and sequences are 
created with a function typelib_TypeDescription_new. 
The description of a base type is initially part of 
type repository. A function that gets a type 
description is function 

typelib_TypeDescription_getByName in the type 
repository API. 

A JAVA API to a type repository is different for 
two reasons. First, the JAVA classes cannot access the 



binary representation of the type descriptions 
directly. Second, the JAVA runtime system provides an 
API (core reflection) similar to the type repository 
API. Unfortunately, the features "unsigned", "oneway" 
and "out parameters" are missing in this API . For this 
reason, additional information is written into the JAVA 
classes to provide the functionality of these features. 

The representation of the types depends on the 
hardware, the language and the operating system. The 
base type is swapped, for example, if the processor has 
little or big endian format. The size of the types may 
vary depending on the processor bus size. The 
alignment is processor and bus dependent. The 
alignment of the data structure is defined as follows: 
Structure members are stored sequentially in 
the order in which the structure members are 
declared. Every data object has an alignment- 
requirement. For a structure, the alignment 
requirement is determined the largest object of 
the structure. Every object is allocated an 
offset so that offset % alignment -requirement == 
0 . 

If it is possible that the maximum alignment can 
be restricted (MICROSOFT C/C++ compiler, IBM C/C++ 
compiler) , the maximum alignment is set to eight . 
Under this condition, the alignment is set to min ( n, 
sizeof ( item ) ) where n is maximum alignment. The 
size is rounded up to the largest integral base type. 
For the MICROSOFT and IBM C/C++ compiler the alignment 
of a structure is set to eight using the "#pragma" 
statement . 

Table 5 shows the type and type definitions for 
one embodiment of the UNO, C++ and the JAVA execution 
environments . 
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Table 5. 





Environment 


Type 


UNO 


C++ 


JAVA 


Byte 


Signed 8 Bit 


Signed 8 Bit 


Signed 8 Bit 


Short 


Signed 16 Bit 


Signed 16 Bit 


Signed 16 Bit 


Ushort 


Unsigned 16 Bit 


Unsigned 16 Bit 


Signed 16 Bit 


Long 


Signed 32 Bit 


Signed 32 Bit 


Signed 32 Bit 


Ulong 


Unsigned 32 Bit 


Unsigned 32 Bit 


Signed 32 Bit 


Hyper 


Signed 64 Bit 


Signed 64 Bit 


Signed 64 Bit 


Uhyper 


Unsigned 64 Bit 


Unsigned 64 Bit 


Signed 64 Bit 


Float 


Processor 
dependent : 
Intel, Sparc = 
IEEE float 


Processor 
dependent : 
Intel, Sparc = 
IEEE float 


IEEE float 


Double 


Processor 
dependent : 
Intel, Sparc = 
IEEE double 


Processor 
dependent : 
Intel, Sparc = 
IEEE double 


IEEE double 


Enum 


The size of a 
machine word. 
Normally, this 
is the size of 
an integer. 


The size of a 
machine word . 
Normally, this 
is the size of 
an integer. 


All enum values 
of one enum 
declaration are 
a static object 
of a class. 
Each object 
contains a 32- 
bit value, which 
represents the 
enumeration 
value . 


Boolean 


1 Byte . 


1 Byte. 


Boolean 


Char 


16 Bit on WNT, 
W95, W98, and 
0s2 . 32 Bit on 
Unix 


16 Bit on WNT, 
W95, W98, and 
0s2 . 32 Bit on 
Unix 


Unsigned 16 bit 
(char) 


String 


A pointer to a 
structure which 


A. pointer to a 
structure which 


j ava . lang . String 
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Environment 


Type 


UNO 


C++ 1 






lave the I 


lave the 






following 


[following 






nembers : 


nembers : 






Long re f Count ; 


Long re f Count; 






long length; 


Long length; 






rfchar_t 


rfchar_t 






buffer [. . .] ; 


ouf fer [...]; 






The string in 


rhe string in 






buffer is 0 


buffer is 0 






terminated. 


terminated. 






This is the 


This is the 






rtl_wString 


rtl_wString 






structure in 


structure in 






the rtl- library 


the rtl -library 


. . 


Structure 


The structure 
contains the 
members in the 
order of the 
declaration. 


The structure 
contains the 
members in the 
order of the 
declaration. 


A class, which 
is derived from 
j ava . lang . Obj ect 
and contains the 
members in the 
specified order. 




The size is 4 + 


The size is 4 + 






size of the 


size of the 






largest type. 


largest type. 






In front of the 


In front of the 






union members 


union members 




Union 


is a long value 
(nSelect) , 
which describes 
the position of 
the valid 
member (0 is 
the first) . 


is a long value 
(nSelect) , 
which describe 
the position of 
the valid 
member (0 is 
the first) . 


Not specified 


Sequence 


A pointer to a 
structure which 
has the 


A pointer to a 
structure which 
has the 


A normal JAVA 
array . 
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Environment 


1 


Type 


UNO 


C+ + 


JAVA | 




z o 1 1 ow i ng 


: o 1 1 ow i ng 






lembers : r 


tiembers : 














dE 1 ement s ,* 


^Elements ; 






.on^ nEl etnent s ; 


ong nElements; 






Long nRef Count ; 


Long nRef Count ; 






rhe pElements 


The pElements 






are a memory 


are a memory 






area that 


area that 






contains 


contains 






nElements 


nElements 






elements . 


elements . 










A class, which 








is derived from 


Exception 


Looks like a 
structure 


Looks like a 
structure 


j ava . lang . Except 
ion and contains 
the members in 
the specified 
order . 






Is a pointer to 




Interface 


Is a pointer to 
a function 
table, which 
contains at 
least three 
functions . 


a C++-Class 
which 
implements 
first the 
virtual methods 
guerylnterf ace , 
acquire and 
release . 


A normal JAVA 
interface . 




A structure 


A. structure 


A class which is 




that contains a 


that contains a 


derived from 




pointer to a 


pointer to a 


„ j ava . lang . Ob j ec 


Any 


type 


type 


t". The members 




description. 


description. 


are a class, 




The second 


The second 


which describe 




member is a 


member is a 


the type of the 
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Environment 


Type 


UNO 


C+ + 


JAVA 




pointer to the 
value stored in 
the any. 


pointer to the 
value stored in 
the any. 


value . A second 
member which is 
the value of the 
any. 


Void 


No memory 
representation 


No memory 
representation 


No memory 
representation 



Many of the types in TABLE 5 are self-explanatory 
and known in the art. Nevertheless, the most relevant 
types are explained in more detail below. 

5 

Interfaces : 

All interfaces employed in connection with the 
present embodiment are derived from a super- interface 

10 class. Each interface contains at least three methods. 
Two methods "acquire" and "release" are necessary to 
control the lifetime of the interface. A third method 
"querylnterf ace" is used to navigate between different 
interfaces. In the UNO environment, an interface 

15 XInterface includes only these three methods. All 
other interfaces in the UNO environment are derived 
from this interface XInterface. 

In a JAVA environment, for example, interfaces are 
mapped to JAVA interfaces, which could be normally 

2 0 implemented. Methods acquire and release are not 

mapped to the JAVA program, since these methods do not 
exist in the JAVA programming language The lifetimes 
of the proxy and the relevant information in a second 
JAVA program are controlled by a garbage collector, and 

25 so methods acquire and release are not needed. The 

JAVA programming language delivers basic types by value 
and non-basic types by reference. All calls are 
specified by value except interfaces. In a JAVA 
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environment, all non-basic types returned or delivered 
through out parameters are by value, which means that 
the implementation must copy any non-basic types before 
return or deliver. 

In a c++ environment, for example, interfaces are 
mapped to pure virtual classes. To automatically 
control the lifetime of interfaces a template called 
"Reference" is used. All return, parameter and member 
types are "References" (e.g.: Reference< XInterface >) . 
The "Reference" acquires the interface when it is 
constructed, and releases the interface when it is 
destructed. 

Structure : 

A structure is a collection of elements. The type 
of each element is fixed and it cannot be changed. The 
number of elements is fixed. 

Exceptions : 

An exception is a program control construct 
besides the normal control flow. One major feature of 
exceptions is that with exceptions, implementation of 
the error handling is simpler. Exceptions are similar 
to structures since exceptions are also a collection of 
elements and each type of each element is fixed and 
cannot be changed and the number of elements is also 
fixed. An additional feature of exceptions is that 
exceptions can be thrown by a method. All exceptions, 
which can be thrown by a method, must be declared at 
the method, except for the exception Runt imeExcept ion, 
which always can occur. All exceptions must be derived 
from interface Exception in the UNO environment. (See 
commonly filed and commonly assigned U.S. Patent 
Application Serial No. 09/xxx,xxx, entitled "A NETWORK 
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PORTAL SYSTEM AND METHODS" of Matthias Hiitsch, Ralf 
Hofmann and Kai Sommerfeld (Attorney Docket No. 4595), 
which is incorporated herein by reference in its 
entirety. If an exception is declared at a method, the 
5 method is allowed to throw all derived exceptions. The 
caller of a method must respond to this behavior. 

In the JAVA environment, for example, all 
exceptions are derived from exception 

j ava . lang . Exception . The exceptions are declared at 
10 the methods. In the C++ environment, for example, the 
exceptions are generated as structures. An exception 
is thrown as an instance (e.g.: throw 

Runt imeExcept ion () ) . At the other side, the exception 
should be caught as a reference 
15 (... catch (RuntimeException & ) { ... }). 

Union : 

A union contains one element. The declaration of 
20 a union specifies the possible types. 

Array : 

An array contains any number of elements. The 

2 5 type of the elements is fixed and cannot be changed. 

Any: 

An any contains one element. All types of 
30 elements are possible. An any contains a reference to 
the value and the type description of the type. With 
the type description, the bridge can transform the 
value, if necessary. In the JAVA environment, the any 
is, for example, represented by class Any, which 

3 5 contains a class as type description and a value, which 

is "j ava . lang .Object" . The basic types are wrapped to 
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their proper classes. For example, a Boolean value is 
an object of the class u j ava . lang . Boolean" , which 
contains the value. 

In the C++ environment, the any is represented 
through class Any. Each type generated by a C++ code 
maker implements a function "getCppuType" . This 
function is used to implement the template access 
operators "<<=" and ">>=" . These operators insert and 
extract the value of the any. 

Sequence : 

A sequence is a generic data type. A sequence 
contains the number of elements and the elements. In 
the JAVA environment, the specification of an array 
fulfills this specification. This is not true for the 
C++ environment. An array in the C++ programming 
language does not contain the number of elements. It 
is not possible to return a C++-array, e.g., Char[] 
getNameO is not possible. It is difficult to manage 
the lifetime between the called and the caller, if only 
a pointer is returned. Therefore, in the C++ 
programming language, a sequence is a template with the 
name Sequence. The implementation contains a pointer 
to a structure, which contains a pointer to the 
elements, the number of elements and the reference 
count. Thus, the implementation of the template holds 
the binary specification. It is cheap to copy this 
sequence, because only the reference count is 
incremented. 

Creating and using a Proxy Interface 

With this understanding of an execution 
environment, and the various types that may be 
associated with an execution environment, a description 
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of making and using one embodiment of a bridge 
including a proxy interface is now described. A bridge 
includes two mappings. Each mapping is dependent upon 
the counterpart mapping, because performing a call may 
require conversion of interfaces from one environment 
to the other environment, e.g., input parameters to an 
interface, and/or return values from an interface. 
Thus, a bridge implements infrastructure to exchange 
interfaces between two environments and is bi- 
directional . 

Figure 4 is a sequence diagram for one embodiment 
the present invention. Along the horizontal axis are 
individual objects, where each object is represented as 
a labeled rectangle. For convenience, only the objects 
needed to explain the operation are included. The 
vertical axis represents the passage of time from top 
to bottom of the page. Horizontal lines represent the 
passing of messages between objects. A dashed line 
extends down from each rectangle, and a rectangle along 
the dashed line represents the lifetime of the object. 

To make calls to a first binary specification for 
an execution environment, the execution environment has 
to be denominated. In one embodiment, an execution 
environment is denominated by a string, because the 
string is extensible and the risk of double names is 
low. Example of strings used to denominate execution 
environments are presented in Table 6 . 



TABLE 6 . : EXAMPLES OF STRINGS USED TO DENOMINATE 
EXECUTION ENVIRONMENTS 



LANGUAGE BINDING OR OBJECT MODEL 


NAMING 


Binary UNO 


uno 


JAVA 


j ava 


MICROSOFT C++ 4.2 - 6.0 


msci 


EGCS 2.9.1 with RTTI 


egcs29 
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Workshop Compiler 5.0 


sunpro5 


COM 


com 



Each bridge is implemented in a separate shared 
library that is loaded at runtime. One naming scheme 
of the library is a concatenation as follows: 

5 

[purpose_] SourceEnvName_DestEnvName 



The optional purpose denotes the purpose of the 
bridge, e.g., protocolling traffic between two 

10 environments. If no purpose is given, the bridge maps 
interfaces from the source environment to the 
destination environment. 

Hence, in this embodiment, user object 401 calls a 
method GetEnvironment , with a string denominating the 

15 source environment as a parameter, in runtime 

library 402. In response to the call, a source 
environment object 403 is instantiated and registered 
by runtime library 4 02. 

User object 401 calls a method GetEnvironment, 

20 this time with a string denominating the destination 

environment as a parameter, in runtime library 402. In 
response to this call, a destination environment 
object 404 is instantiated and registered by runtime 
library 4 02 . 

25 Next, user object 401 calls a method getMapping in 

runtime library 402. A first parameter in the method 
call is the string denominating the source environment. 
A second parameter in the method call is the string 
denominating the destination environment. 

30 In response to the call to method getMapping, a 

bridge object 405 is activated by runtime library 402. 
In one embodiment, a shared library is searched to find 
a library that contains a proxy factory for the 
specified source and destination environments. In a 
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JAVA execution environment, the search is for a class 
with a name associated with the source and destination 
environments. The shared bridge library cannot be 
unloaded while any of its code is still needed. So 
both mappings and any wrapped interface (proxy) that 
are exported need to modify a shared bridge library 
wide reference count. If the shared bridge library can 
be unloaded the reference count goes to zero. 

After bridge object 405 is activated, user 
object 401 issues a call to a method 

Mapping. maplnterf ace with a first parameter that is a 
source interface, and a second parameter that is a 
type. After receiving the call to method 
Mapping. maplnterf ace, bridge object 405 issues a call 
to method sourceEnv.getObject Identifier of source 
environment object 403 for the type. An object 
identifier is returned for the type, e.g., for an 
interface, and bridge object 405 issues a call to 
method destEnv.getRegisteredlnterf ace of destination 
environment object 4 04 with the object identifier and 
the type as input parameters . 

If a proxy interface is registered in destination 
environment object 4 04 for this object identifier and 
type, a pointer to the proxy is returned by method 
getRegisteredlnterface . In this example, a pointer to 
the proxy interface 406 is returned to user object 401. 

Conversely, if method getRegisteredlnterface 
failed to find a registered proxy interface, bridge 
object 405 calls method create proxy with a source 
environment and a type as input parameters . In 
creating a proxy, bridge object 4 05, in one embodiment, 
uses a proxy factory to generate method code to 
implement each method specified in the interface to be 
created. The only information to do this is a type 
description of the interface. For example, in a JAVA 
environment, a binary class file (*. class) is generated 
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and loaded with the class loader. In the absence of a 
loader, which can directly load binary classes, a 
loader has to be provided. In a C++ environment, 
virtual method tables are generated, which delegate 
5 each call to the interface in the source environment. 

The knowledge of the type description is necessary 
to create the proxy, as described. This type 
description is the full description of the limited 
functionality, e.g., a description of an interface, in 

10 the source execution environment. The type description 
may refer one of the different types shown in Table 5 . 

Following creation of the proxy, bridge object 4 05 
registers the interface with source environment 
object 4 03 and registers the proxy interface with 

15 destination environment object 404. This completes 
creation of proxy interface 406, sometimes called 
proxy 4 06. 

To use proxy interface 406, user object 401 simply 
calls a method in proxy interface 406. In response to 

2 0 the call, proxy interface 4 06 converts any input 

parameters as necessary using the method type 
description, and marshals the arguments for source 
interface 407. Next, proxy interface 406 dispatches a 
call to the method in source interface 407 in the 
25 source execution environment. 

The method is executed in the source environment 
and the results are returned by source interface 407 to 
proxy interface 4 06. Upon receiving a return for the 
call, proxy interface 406 checks for any exceptions and 

3 0 if there are none, converts any output parameters and 

the return value to the destination execution 
environment again using the method type description, 
and then returns the results to user object 401. Thus, 
user object 401 has transparently accessed 
3 5 functionality in another execution environment. 
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Typically, this is limited functionality, as described 
above . 

In the following description, a specific example 
of a bridge that maps an interface from a MICROSOFT 
5 Visual C++ environment to a UNO environment is first 
described, and that maps an interface from a UNO 
environment to a MICROSOFT Visual C++ environment is 
described second. Table 7 is an example of a call to a 
method bar in the UNO interface XExample from a C++ 
10 program. 

TABLE 7 . : EXAMPLE of C++ PROGRAM SEGMENT TO GENERATE 
and USE A PROXY 



Mapping aMapping ( "uno" , "msci" ) ; 

XExample * pExample = (XExample *) 

aMapping . maplnterf ace ( pUnoExample, 

: : getCppuType ( {const Reference < XExample > *) 0 

) ) ; 

pExample- >bar () ; 
pExample- >release ; 



15 

For the example of Table 1, the initial call to 
function Mapping creates a bridge from the UNO 
environment to the MSCI environment. The generation of 
the bridge, in this example uses, methods 
2 0 i nit Environment and getMapping. Table 8 is the 

implementation of these methods that are used in the 
proxy class of Table 9, for this example. 
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TABLE 8 . : EXAMPLE OF DECLARATION OF METHODS 
initEnvironmexit and getMapping. 



extern "C" SAL_DLLEXPORT 


void 


SAL_CALL 


uno__init Environment 


( uno 


Environment * pCppEnv ) 


{ 

CPPU_CURRENT_NAMESPACE : : 


cppu_ 


cppenv initEnvironment ( 


pCppEnv ) ; 

} 






extern "C" SAL_DLLEXPORT 


void 


SAL_CALL 


uno__ext_get Mapping ( 


uno_ 


Mapping ** ppMapping, 


uno Environment * pFrom, 


uno_Environment * pTo ) 


I 

CPPU_CURRENT_NAMESPACE : : 


cppu_ 


ext_getMapping ( ppMapping, 


pFrom, pTo ) ; 

} 







As explained above, to process a call to a method 
of a UNO interface in the C++ environment, there must 
be a proxy C++ object that delegates the method call to 
the corresponding UNO interface. Table 9 is bridge 

10 header file example of a bridge class, a C++ to UNO 

proxy class, and a UNO to C++ proxy class that can be 
modified for a specific environment. This example uses 
the bridge object and C++ to UNO proxy object that are 
instantiated using the classes in Table 9. As 

15 explained above, the call to method 

Mapping. maplnt erf ace creates a proxy interface. 

TABLE 9.: EXAMPLE OF A CLASS DEFINITIONS 
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namespace CPPU_CURRENT_NAME SPACE 



// these have to be defined in some C file in the 
// current namespace (See Tables 10 & 16) 
void SAL_CALL cppu_cpplnterf aceProxy_patchVtable ( 
:: com: : sun: : star :: uno : :XInterf ace * pCppI, 
typelib_Interf aceTypeDescription * pTypeDescr ) ; 
void SAL_CALL cppu_unoInterf aceProxy_dispatch ( 
uno_Interface * pUnoI, const 

typelib_TypeDescription * pMemberDescr , void * 
pReturn, void * pArgsf], uno__Any ** ppException 

//================================================== 

struct cppu_Bridge ; 

struct cppu_Mapping : public uno_Mapping 
{ 

cppu_Bridge * pBridge; 

inline cppu_Mapping ( cppu_Bridge * pBridge, 
uno_Map!nterf aceFunc fpMap ) ; 



/ /==== holding environments and mappings 
struct cppu_Bridge 



oslInterlockedCount nRef; 
uno_Ext Environment * pCppEnv; 
uno_ExtEnvironment * pUnoEnv; 
cppu_Mapping aCpp2Uno; 
cppu_Mapp i ng aUno 2 Cpp ; 

sal_Bool bExportCpp2Uno; 
void SAL_CALL acquire(); 
void SAL_CALL release (); 

inline cppu_Bridge ( uno_ExtEnvironment * pCppEnv_ 
uno_Ext Environment * pUnoEnv_, sal_Bool 
bExportcpp2Uno_ ) ; 

}; 

//==== a cpp proxy wrapping an uno interface ==== 
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struct cppu_cppInterfaceProxy : public 
: :com: : sun : : star : : uno : :XInterface 



osl Inter lockedCount 



cppu_Bridge * 

// mapping information 

uno_Interf ace * 



nRef ; 
pBridge ; 



pUnoI ; // wrapped interface 



typelib_InterfaceTypeDescription * pTypeDescr; 

: :rtl : :OUString oid '" 

// non virtual methods called on incoming vtable calls 

// #1, #2 

inline void SAL_CALL acquireProxy ( ) ; 
inline void SAL_CALL releaseProxy ( ) ; 

// XInterface: these are only here for dummy, there 
will be a patched vtable! 

// dont use this, use cppu_querylnterf ace ( ) ! 

virtual :: com :: sun :: star :: uno :: Any SAL_CALL 

querylnterf ace ( const :: com: : sun :: star :: uno :: Type 
& ) { return :: com: : sun :: star :: uno : :Any () ; } 

// dont use this, use cppu_acquire ( ) ! 

virtual void SAL__CALL acquire () {} 

// dont use this, use cppu_release ( ) ! 

virtual void SAL_CALL release () {} 

// ctor 

inline cppu_cpplnterf aceProxy ( cppu_Bridge * pBridge__, 
uno_Interf ace * pUnoI_, 

typelib_Interf aceTypeDescription * pTypeDescr_, 
const : :rtl : :OUString & rOId_ ) ; 



//= a uno proxy wrapping a cpp interface ==== 
struct cppu_unoInt erf aceProxy : public uno_Interf ace 
{ 

oslInterlockedCount nRef; 



cppu_Bridge * 



pBridge; 
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// mapping information 

: : com : : sun : : star : : uno : : XInterf ace * pCppI ; / / 

wrapped interface 
typelib_InterfaceTypeDescription * pTypeDescr; 
: :rtl : rOUString Old; 
II ctor 

inline cppu_unoInterf aceProxy ( cppu_Bridge * pBridge_, 
:: com: : sun: : star :: uno: : XInterf ace * pCppI_, 
typelib_InterfaceTypeDescription * pTypeDescr_, 
const : :rtl : :OUString & rOId_ ); 

}; 

// 

inline void SAL_CALL cppu_cppenv_initEnvironment ( 
uno_Environment * pCppEnv ) ; 

// 

inline void SAL_CALL cppu_ext_getMapping ( uno_Mapping 

** ppMapping, uno_Environment * pFrom, 

uno_Environment * pTo ) ; 

} 



The proxy object is instantiated and the vtable 
pointer is modified to give a generic vtable. For a 
MICROSOFT C++ environment, the generic vtable can be 
5 used because an objects' this pointer is at anytime the 
second stack parameter (See Fig. 6) . However, for gcc 
or sunpro5 (See Table 6) , the first parameter may the 
pointer to a struct return space. Thus, for there 
compilers, a vtable for each type that is used must be 
10 generated. 

As explained more completely below, when the proxy 
interface is called, a vtable index is determined by 
the generic vtable (See Figs. 7A and 7B) , and based 
upon this index, the method type description is 
15 determined. This method type description is the 
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information that is used to get the values from the 
processor call stack and perform a dispatch call on the 
target UNO interface that the C++ proxy is wrapping. 
After the dispatch call, the returned exception 
5 information is checked to determine whether a C++ 
exception has to be generated and raised. If no 
exception has occurred, the inout/out parameters are 
reconverted. In this example, the reconversion of 
inout/out parameters is only important for values 

10 representing interfaces or values containing 

interfaces, because the values of all objects in the 
UNO environment are binary compatible on a specific 
computing architecture. 

The C++ proxy, as defined by Table 9, holds the 

15 interface origin, i.e., the target UNO interface. 
Thus, the C++ proxy can register with the C++ 
environment on the first execution of method acquire, 
and can revoke itself on its last execution of method 
release from its environment . 

2 0 The C++ proxy manages a reference count for the 

proxy, a pointer to the bridge of the C++ proxy to 
obtain the counterpart mapping, the UNO interface the 
C++ proxy delegates calls to, the (interface) type the 
C++ proxy is emulating, and an object identifier (oid) . 

2 5 The type and object identifier are needed to manage 

objects from environments, for proof of object 
identity, and to improve performance. A proxy to an 
interface is not needed if there is already a 
registered proxy for that interface. 

3 0 When the proxy object is created by the MICROSOFT 

Visual C++ compiler, the vtable is patched by the 
execution of method patchVtable . One embodiment of 
method patchVtable is presented in TABLE 10. 
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TABLE 10.: EXAMPLE OF METHOD patchVtable 



void SAL_CALL cppu_cpplnterf aceProxy_patchVtable ( 
XInterface * pCppI , 

typelib_Interf aceTypeDescription * pTypeDescr ) 

{ 

static MediateVtables * s_pMediateVtables = 0 ; 

if (! s j)MediateVtables) 

{ 

MutexGuard aGuard ( Mutex : : getGlobalMutex ( ) ) ; 

if (! s_pMediateVtables) 

{ 

#ifdef LEAK_S TAT I C_DATA 

s_pMediateVtables = new MediateVtables () ; 

#else 

static MediateVtables s_aMediateVtables ; 

s_pMediateVtables = &s_aMediateVtables ,- 
#endif 
} 
} 

* (const void **)pCppI = s_pMediateVtables- 
>getMediateVtable ( pTypeDescr- 
>nMapFunctionIndexToMemberIndex ) ; 

} 



An embodiment of the class MediateVtables that is 
5 used to instantiate the object MediateVtables in method 
patchVtable is presented in TABLE 11. 

TABLE 11.: EXAMPLE OF CLASS MediateVtables 



class MediateVtables 
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{ 

// 

struct Def aultRTTIEntry 
{ 

sal_Int32 _nO, _nl , _n2 ; 
type_inf o * _pRTTI ; 
Def aultRTTIEntry ( ) 
: _n0 ( 0 ) , 

_nl ( 0 ) , 

_n2 ( 0 ) 

{ _pRTTI = msci_getRTTI ( "com. sun . star . uno . XInt erf ace" 

) ; } 

}; 

typedef list<void * > t_pSpacesList ; 
Mu t ex _aMut ex ; 

t_pSpacesList _aSpaces ; 

sal_Int32 _nCurrent ; 

const void * _j?Current; 
public : 

const void * getMediateVtable ( sal_Int32 

nSize ) ; 

MediateVtables ( sal_Int32 nSize = 256 ) 
: _nCurrent ( 0 ) 
, _pCurrent ( 0 ) 
{ getMediateVtable ( nSize ) ; } 
-MediateVtables () ; 



//_ 



MediateVtables : : -MediateVtables ( ) 
{ 

TRACE ( " > calling -MediateVtables () : freeing mediate 

vtables . . . <\n" ) ; 
MutexGuard aGuard ( _aMutex ) ; 

// this MUST be the absolute last one, which is called! 
for ( t_pSpacesList :: iterator iPos ( _aSpaces . begin ( ) ) ; 
iPos != _aSpaces . end ( ) ; ++iPos ) 



-50- 



AsFiled 
P-4355 



{ 

rtl_f reeMemory ( *iPos ); 

} 

} 



TABLE 12 is an example of one embodiment of a 
method getMediateVtable that is called in the 
embodiment of method patchVtable of TABLE 10. 

TABLE 12 . : EXAMPLE OF METHOD getMediateVtable 



const void * MediateVtables : .-getMediateVtable ( 
sal_Int32 nSize ) 

{ 

if (_nCurrent < nSize) 
{ 

TRACE ( "> need larger vtable! <\n" ) ; 
// dont ever guard each time, so ask twice when guarded 
MutexGuard aGuard ( _aMutex ) ; 
if (_nCurrent < nSize) 
{ 

nSize = (nSize +1) & Oxfffffffe; 

char * pSpace = (char * ) rtl_allocateMemory ( 

( (1+nSize) *sizeof (void *) ) + (nSize*12) ) ; 
_aSpaces .push_back ( pSpace ) ; 
// on index -1 write default rtti entry- 
static Def aultRTTIEntry s_def aultlnterf aceRTTI ; 
* (void **)pSpace = &s_def aultlnterf aceRTTI ; 
void ** pvft = (void **) (pSpace + sizeof (void *)) ; 
char * pCode = pSpace + ( (1+nSize) *sizeof (void *) ) ; 
// setup vft and code 

for ( sal_Int32 nPos = 0; nPos < nSize; ++nPos ) 
{ 

unsigned char * codeSnip = (unsigned char * ) pCode + 
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(nPos *12) ; 
pvft [nPos] = codeSnip; 
/** 

* vtable calls detonate on these code snippets 
*/ 

// mov eax, nPos 

*codeSnip++ = 0xb8 ; 

* (sal_Int32 *)codeSnip = nPos ; 

codeSnip += sizeof ( sal_Int32 ) ; 

// jmp rel32 cpp_vtable_call 

*codeSnip++ = 0xe9; 

*(sal_Int32 *) codeSnip = ((unsigned char 

*) cpp_vtable_call) - codeSnip - sizeof (sal_Int32) ; 

} 

_pCurrent = pSpace + sizeof (void *) ; 
_nCurrent = nSize; 

} 

} 

return _pCurrent ; 
} 





Figure 6 is an example of a call stack 60 0 of a 
virtual function call that is stored in a memory 610 of 
computer system 100 (Figs. 1A and IB) . The left-hand 
5 column is the stack offset for the start of storage 
location, and the right hand column gives the value 
stored at each storage location. 

The vtable for the C++ proxy, i.e., a function 
pointer array to perform polymorphic calls on C++ 
10 objects, determines which function should be called. 
Figure 7A is an illustration of the vtable for this 
example that correlates the slots in the table to the 
methods handled by the C++ proxy. Recall, that every 
proxy has to inherit the methods from UNO interface 
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XInterface, which are methods acquire, release, and 
querylnterf ace . 

When the call to method bar (Table 7) is executed, 
the call is directed to the C++ proxy. The only task 
5 of the proxy vtable is to determine the call index of 
the UNO method that is to be called. (See Fig. 7B) 

Figure 8 is a process flow diagram of one 
embodiment of the operations performed by a proxy 13 0 
or 130A that in this example is the C++ proxy. When 
10 method bar is called, process 800 (Fig. 8) is started 
in operation 8 01. 

Initially, in determine slot operation 802 the C++ 
proxy executes method patchVtable (See Table 10) that 
in turn calls method getMediateVtable (See Table 12) . 
15 Method getMediateVtable reaches an assembler snippet 

that determines the vtable slot of method bar and calls 
method vTable 810. This completes operation 802. 

TABLE 13 is an example of one implementation of 
method vTable 810. 



TABLE 13 . : AN EXAMPLE OF METHOD vTable 



/** 

* is called on incoming vtable calls 

* (called by asm snippets) 
*/ 

static declspec (naked) void cdecl 



20 



cpp_vtable_call (void) 



{ 



asm 




/ / space for 



push esp 
push eax 



// vtable index 
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mov eax, esp 

add eax, 16 

push eax // original stack pt 

call cpp_mediate 
add esp, 12 

cmp eax, typelib_TypeClass_FLOAT 

je Lfloat 

cmp eax, typelib_TypeClass_DOUBLE 

je Ldouble 

cmp eax, typelib_TypeClass_HYPER 

j e Lhyper 
cmp eax, 
t ype 1 i b_Type C 1 a s s_UNS I GNED_H YPER 
je Lhyper 
// rest is eax 
pop eax 
add esp, 4 



Lhyper : 



ret 

pop eax 
pop edx 
ret 

fid dword ptr [esp] 

add esp, 8 

ret 

fid qword ptr [esp] 

add esp, 8 

ret 
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Operation 802 transfers processing to prepare 
stack operation 811 in method mediate 810. In 
operation 811, the stack space is prepared for register 
5 data, and then processing passes to call mediate 
operation 812. 

Call mediate operation 812 calls method mediate 
that in turn looks up the called vtable index, gets the 
attribute or method type description, and calls a 
10 method that dispatches that actual call to the method 
in the UNO environment. A process flow diagram of one 
embodiment of method mediate 900 is presented in 
Figure 9. Table 14 is an example of method mediate. 

15 TABLE 14 . : EXAMPLE OF METHOD mediate 



static typelib_TypeClass cdecl cpp_mediate ( void ** 

pCallStack, sal_Int32 nVtableCall, sal_Int64 * 
pRegisterReturn /* space for register return */ ) 

{ 

OSL_ENSHURE( sizeof (sal_Int32 ) ==sizeof (void *), "### 

unexpected ! " ) ; 
// pCallStack: ret adr, this, [ret *] , params 
// this_ ptr is patched cppu_XInterf aceProxy object 
cppu_cpplnterf aceProxy * pThis = static_cast< 

cppu_cppInterfaceProxy * >( reinterpret_cast< 

XInterface * >( pCallStack [1] ) ) ; 
typelib_InterfaceTypeDescription * pTypeDescr = pThis- 

>pTypeDescr ; 
OSL_ENSHURE( nVtableCall < pTypeDescr- 

>nMapFunctionIndexToMemberIndex, "### illegal 

vtable index!" ) ; 
if (nVtableCall >= pTypeDescr- 

>nMapFunctionIndexToMember Index) 

{ 
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throw Runt imeExcept ion ( OUString( 

RTL_CONSTASCII_USTRINGPARAM ( " illegal vtable 
index!") ), (XInterface *)pThis ); 

} 

// determine called method 
sal_Int32 nMemberPos = pTypeDescr- 

>pMapFunctionIndexToMemberIndex [nVtableCall] ; 
OSL_ENSHURE( nMemberPos < pTypeDescr- >nAllMembers , "### 

illegal member index!" ); 
TypeDescription aMemberDescr ( pTypeDescr- 

>ppAllMembers [nMemberPos] ) ; 
typelib_TypeClass eRet; 

switch (aMemberDescr .get () ->eTypeClass) 
{ 

case typelib_TypeClass_INTERFACE_ATTRlBUTE : 

{ 

if (pTypeDescr- 

>pMapMetnberIndexToFunctionIndex [nMemberPos] == 
nVtableCall) 

{ 

// is GET method 

eRet = cpp2uno_call ( pThis, aMemberDescr . get () , 
( (typelib_InterfaceAttributeTypeDescription 
*) aMemberDescr .get () ) ->pAttributeTypeRef, 0, 0, 
pCallStack, pRegisterReturn ) ; 

} 

else 
{ 

// is SET method 

typelib_MethodParameter aParam; 

aParam . pTypeRef 

= ( (typelib_Interf aceAttributeTypeDescription 
* ) aMemberDescr . get ( ) ) - >pAttributeTypeRef ; 

aParam.bin = sal_True; 

aParam.bOut = sal_False; 

eRet = cpp2uno_call ( pThis, aMemberDescr .get (), 0 , 1, 
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&aParam, pCallStack, pRegisterReturn ) ; 

} 

break; 
} 

case type 1 i b_Type C las s_I NTERFACE_METHOD : 
{ 

// is METHOD 

switch (nVtableCall) 

{ 

// standard XInterface vtable calls 
case 1: // acquire () 

pThis- >acquireProxy ( ) ; // non virtual call I 

eRet = typelib_TypeClass_VOID; 

break ; 
case 2: // release () 

pThis->releaseProxy () ; // non virtual call! 

eRet = typelib_TypeClass_VOID; 

break; 

case 0: // querylnterf ace () opt 
{ 

typelib_TypeDescription * pTD = 0; 

TYPELIB_DANGER_GET ( &pTD, reinterpret_cast < Type * >( 

pCallStack[3] ) - >getTypeLibType ( ) ); 
OSL_ASSERT ( pTD ) ; 
XInterface * plnterface = 0; 

(*pThis- >pBridge->pCppEnv->getRegisteredInterf ace) ( 
pThis- >pBridge->pCppEnv, (void ** ) &plnterf ace , 
pThis - >oid . pData , 

(typelib_Interf aceTypeDescription *)pTD ); 
if (plnterface) 
{ 

uno_any_construct ( reinterpret_cast< uno_Any * >( 

pCallStack [2] ), kplnterf ace, pTD , cpp_acquire 
) ; 

plnterface- >release ( ) ; 
TYPELIB_DANGER_RELEASE ( pTD ) ; 
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* (void **)pRegisterReturn = pCallStack [2 ] ; 

eRet = typelib_TypeClass_ANY; 

break; 

} 

TYPELIB_DANGER_RELEASE ( pTD ) ; 

} // else perform querylnterf ace ( ) 

default : 

eRet = cpp2uno_call ( 

pThis, aMemberDescr .get ( ) , 

( ( typelib_Interf aceMethodTypeDescript ion 

*) aMemberDescr .get () ) - >pReturnTypeRef , 

( (typelib_Interf aceMethodTypeDescript ion 

* ) aMemberDescr . get ( ) ) - >nParams , 

( (typelib_Interf aceMethodTypeDescript ion 

*) aMemberDescr . get () ) ->pParams, pCallStack, 

pRegisterReturn ) ; 

} 

break; 
} 

default : 
{ 

throw Runt imeExcept ion ( 

OUString( RTL_CONSTASCII_USTRINGPARAM ( "no member 

description found!") ), (XInterface *)pThis ); 
// is here for dummy 
eRet = typelib_TypeClass_VOID; 
} 
} 

return eRet; 
} 



Method call check 901 of method mediate 900 
determines whether the call is a method call. If the 
call is a method call processing transfers to 
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acquire/release check operation 910, and otherwise to 
attribute get check operation 920. 

Acquire/release check operation 910 branches to 
acquire/release call operation 911 if the method call 
5 is a call to either method acquire or method release, 
because these calls can be executed without calling the 
interface in the source environment. If the method 
call is not a call to either method acquire or method 
release, processing transfers from check operation 910 
10 to query interface check operation 912. 

Acquire/Release call operation 911 performs the 
appropriate method, which is a non-virtual call, and 
returns . 

Query interface check operation 912 determines 
15 whether the method call is to method querylnterf ace . 
If the method call is not to method querylnterf ace , 
check operation 912 transfers to call Envl_to_Env2 with 
Interface operation 93 0 and otherwise transfers to 
registered interface available check operation 913. In 

2 0 the current example, the call to method bar results in 

check operation 912 transferring to operation 930. 

Nevertheless, to complete the description of this 
branch of method mediate 900, if there is a registered 
interface in the source environment object for method 
25 querylnterf ace, check operation 913 transfers to set 
return value operation 914 and otherwise to call 
Envl_to_Env2 with Interface operation 93 0. Asking 
whether the interface is registered in the source 
environment object is an optimization that eliminates a 

3 0 call to the actual interface in the source environment. 

Set return value operation 914 sets the registered 
interface as the return value and returns. 

If the call to the C++ proxy was not a method 
call, check operation 901 transfers to attribute get 
35 check operation 920. In this embodiment, there is 

either an attribute get or an attribute set. If the 
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call to the proxy is an attribute get, check 
operation 920 transfers to prepare attribute get call 
operation 921 and otherwise transfers to prepare 
attribute set call operation 922. Both operations 921 
5 and 922 set up the parameters for the call and transfer 
to call Envl_to_Env2 with Interface operation 930. 

An embodiment of method Envl_to_Env2 with 
interface for the C++ proxy is presented in Table 15 . 
Figure 10 is a process flow diagram for one embodiment 
10 of method Envl_to_Env2 with interface. 

TABLE 15.: AN EXAMPLE OF METHOD Envl_to_Env2 with 
interface 



using namespace std; 
using namespace rtl; 
using namespace osl; 

using namespace com: : sun :: star :: uno ; 
namespace CPPU_CURRENT_NAME SPACE 
{ 

static inline type lib_TypeCl ass cpp2uno_call ( 
cppu_cpp Inter face Proxy * pThis, const 
typelib_TypeDescription * pMemberTypeDescr , 
typelib_TypeDescriptionRef erence * pReturnTypeRef , 
sal_Int32 nParams, typelib_MethodParameter * 
pParams, void ** pCallStack, 
sal_Int64 * pRegisterReturn ) 

{ 

// pCallStack: ret, this, [complex return ptr] , params 
char * pCppStack = (char *) (pCallStack +2) ; 
/ / return 

typelib_TypeDescription * pReturnTypeDescr = 0 ; 
if (pReturnTypeRef) TYPELIB_DANGER_GET ( 

&pReturnTypeDescr , pReturnTypeRef ) ; 
void * pUnoReturn = 0; 
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// complex return ptr: if != 0 && != pUnoReturn, 

// reconversion need 

void * pCppReturn = 0; 

if (pReturnTypeDescr) 

{ 

if (cppu_isSimpleType ( pReturnTypeDescr )) 
{ 

// direct way for simple types 
pUnoReturn = pRegisterReturn; 
} 

else / / complex return via ptr (pCppReturn) 
{ 

pCppReturn = * (void **) pCppStack; 
pCppStack += sizeof(void *) ; 

pUnoReturn = (cppu_relatesToInterf ace ( pReturnTypeDescr 
) 

// direct way 
? alloca( pReturnTypeDescr- >nSize ) : pCppReturn); 

} 
} 

// stack space 

OSL_ENSHURE ( sizeof (void *) == sizeof (sal_Int32 ) , "### 

unexpected size!" ); 
// parameters 

void ** pUnoArgs = (void **)alloca( 4 * sizeof (void *) 

* nParams ) ; 

void ** pCppArgs = pUnoArgs + nParams; 

// indices of values that have to be converted 

// (interface conversion cpp<=>uno) 

sal_Int32 * pTempIndizes = (sal__Int32 *) (pUnoArgs + (2 

* nParams) ) ; 

// type descriptions for reconversions 
typelib_TypeDescription ** ppTempParamTypeDescr = 

(typelib_TypeDescription **) (pUnoArgs + (3 * 

nParams) ) ; 
sal_Int32 nTempIndizes = 0 ; 
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for ( sal_Int32 nPos = 0; nPos < nPararas; ++nPos ) 
{ 

const typelib_MethodParameter & rParam = pParams [nPos] ; 
typelib_TypeDescription * pParamTypeDescr = 0 ; 
TYPELIB_DANGER_GET ( &pParamTypeDescr , rParam. pTypeRef 
) ; 

if (! rParam . bOut && cppu_isSimpleType ( pParamTypeDescr 
)) // value 

{ 

pCppArgs [nPos] = pCppStack; 

pUnoArgs [nPos] = pCppStack; 

switch (pParamTypeDescr- >eTypeClass) 

{ 

case typelib_TypeClass_HYPER: 

case typelib_TypeClass_UNSIGNED_JIYPER : 

case typelib_TypeClass_DOUBLE: 

pCppStack += sizeof (sal_Int32) ; // extra long 
} 

//no longer needed 

TYPELIB_DANGER_RELEASE ( pParamTypeDescr ) ; 
} 

else // ptr to complex value | ref 
{ 

pCppArgs [nPos] = * (void **) pCppStack; 

if (! rParam.bin) // is pure out 

{ 

// uno out is uncons true ted mem! 

pUnoArgs [nPos] = alloca ( pParamTypeDescr- >nSize ); 
pTempIndizes [nTempIndizes] = nPos; 
// will be released at reconversion 

ppTempParamTypeDescr [nTempIndizes++] = pParamTypeDescr; 
} 

// is in/inout 

else if (cppu_relatesToInterf ace ( pParamTypeDescr )) 
{ 

uno_copyAndConvertData ( pUnoArgs [nPos] = alloca ( 
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pParamTypeDescr - >nSi ze ), * (void ** ) pCppStack, 
pParamTypeDescr, &pThis->pBridge->aCpp2Uno ) ; 

/ / has to be reconverted 

pTempIndi zes [nTempIndizes] = nPos ; 

// will be released at reconversion 

ppTempParamTypeDescr [nTempIndizes++] = pParamTypeDescr; 
} 

else // direct way 
{ 

pUnoArgs [nPos] = * (void **) pCppStack; 
//no longer needed 

TYPELIB_DANGER_RELEASE ( pParamTypeDescr ) ; 

} 

} 

/ / standard parameter length 
pCppStack += sizeof (sal_Int32) ; 
} 

// ExceptionHolder 

uno_Any aUnoExc; // Any will be constructed by callee 
uno_Any * pUnoExc = &aUnoExc ; 
// invoke uno dispatch call 
(*pThis->pUnoI->pDispatcher) ( pThis->pUnoI , 

pMemberTypeDescr , pUnoReturn, pUnoArgs, &pUnoExc 

) ; 

// in case an exception occurred... 

if (pUnoExc) 

{ 

// destruct temporary in/inout params 

while (nTempIndizes--) 

{ 

sal_Int32 nlndex = pTempIndi zes [nTempIndizes] ,- 
// is in/inout => was constructed 
if (pParams [nlndex] .bin) 
uno_destructData ( pUnoArgs [nlndex] , 

ppTempParamTypeDescr [nTempIndizes] , 0 ) ; 
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TYPELIB_DANGER_RELEASE ( 

ppTempParamTypeDescr [nTempIndizes] ) ; 

L (pReturnTypeDescr) TYPELIB_DANGER_RELEASE ( 

pReturnTypeDescr ) ; 
msci_raiseException( &aUnoExc, & P This->pBridge- 

>aUno2Cpp ) ; // has to destruct the any 
// is here for dummy 
return typelib_TypeClass_VOID; 

} 

else // else no exception occurred... 
{ 

// temporary params 
while (nTempIndizes--) 

Ll_lnt32 nlndex = pTempIndizes [nTempIndizes] ; 
typelib_TypeDescription * pParamTypeDescr = 

ppTempParamTypeDescr [nTempIndizes] ; 
if (pParams [nlndex] .bOut) // inout/out 
{ 

// convert and assign 

uno_destructData( pCppArgs [nlndex] , pParamTypeDescr, 

cpp_release ) ; 
uno_copyAndConvertData ( pCppArgs [nlndex] , 

pUnoArgs [nlndex] , pParamTypeDescr, &pThis- 

> P Bridge->aUno2Cpp ) ; 

} 

// destroy temp uno param 

uno_destructData( pUnoArgs [nlndex] , pParamTypeDescr, 
) ; 

TYPELIB_DANGER_RELEASE ( pParamTypeDescr ) ; 
} 

// return 

if (pCppReturn) // has complex return 
{ 

if (pUnoReturn != pCppReturn) // needs reconversion 
-64- 



AsFiled 
P-4355 



{ 

uno_copyAndConvertData ( pCppReturn, pUnoReturn, 

pReturnTypeDescr , &pThis->pBridge->aUno2Cpp ) ; 
/ / destroy temp uno return 

uno_destructData ( pUnoReturn, pReturnTypeDescr, 0 ) ; 
} 

/ / complex return ptr is set to eax 

* (void **) pRegisterReturn = pCppReturn; 

} 

if (pReturnTypeDescr) 
{ 

typelib_TypeClass eRet = 

( typelib_TypeClass) pReturnTypeDescr- >eTypeClass ; 
T Y PEL I B_DANGER_RELE AS E ( pReturnTypeDescr ) ; 
return eRet ; 
} 

else 

return typelib_TypeClass_VOID ; 

} 

} 



In Figure 10, read parameters operation 1001 reads 
the parameters from the stack. All simple parameters 
are directly accessed on the stack (up to eight bytes) . 
5 All complex structures, e.g., interfaces, are 

referenced by a pointer. Since in this example UNO and 
C++ types have the same binary size (See Table 5) , only 
interfaces need to be exchanged. 

Read parameters operation 10 01 transfers to 
10 convert parameters operation 1002. Convert parameters 
operation 1002, using the parameter type description, 
converts the parameters read to the UNO environment and 
transfers to allocate memory operation 1003. Allocate 
memory operation 1003 allocates memory for the out 
15 parameters returned by the call to the UNO interface, 
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and for the return value. Allocate memory 
operation 1003 transfers processing to dispatch call 
operation 1004. 

Dispatch call operation 1004 calls, in this 
5 example, method bar in UNO interface XExample . In 

general, dispatch call operation 1004 dispatches a call 
to the source interface (See Fig. 4) . The call is 
executed in the source environment and the results, if 
any, are returned to operation 10 04 that in turn 
10 transfers to exception check operation 1005. 

Exception check operation 1005 determines whether 
an exception was thrown in response to the call. If an 
exception was thrown, check operation 1005 transfers 
processing to clean up operation 1110 and otherwise 
15 processing transfers to convert parameters 
operation 1020 . 

Clean up operation 1010 cleans up any temporary 
parameters that were created in the call in 
operation 1004. Operation 1010 transfers to throw 

2 0 exception operation 103 0 that in turn throws an 

exception in the destination environment based upon the 
exception received from the call to the source 
environment . 

If an exception was not thrown in the source 

25 environment, convert parameters operation 1020 converts 
any parameters that were returned from operation 1004, 
e.g., out parameters and/or inout parameters using the 
parameter type description, from the source environment 
to the destination environment, and transfers to clean 

30 up operation 1021. Clean up operation 1021 cleans up 
any temporary parameters that were created in the call 
in operation 1004 and transfers to convert return value 
operation 1022. Operation 1022 converts any return 
value from the source environment to the destination 

3 5 environment so that both the return value and any 

returned parameters are written back, in this example 
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to C++. Processing returns to mediate method 900 that 
in turn returns to fill return registers 813 in method 
vTable 810. 

In fill return registers operation 813, if the 
5 type is one of float, double, hyper, or unsigned hyper, 
an appropriate action is taken to properly fill the 
return registers. Otherwise, a 32 -bit integer is 
placed in register eax. See Table 13 for one 
embodiment of operation 813. 

10 The above example assumed that the original call 

was in a C+ + environment and was directed to a method 
of an interface in the UNO environment . In the 
embodiment of Figure 1A, another possibility is that a 
call is made in the UNO environment, i.e., 

15 environment 120 to a C++ method in environment 150. In 
this case, the bridge and proxy would be in the UNO 
environment. Alternatively, in Figure IB, the 
intermediate environment is a UNO environment. 

In this embodiment, struct cppu_unoInterf aceProxy 

20 in Table 9 is used to instantiate the UNO proxy that 
wraps a C++ interface. As explained more completely 
below, when the proxy interface is called, a check is 
made to determine if a method of the proxy interface 
has been called. If a method was called, any input 

25 parameters are converted using the type description and 
pushed on a processor stack, and then a call is 
dispatched to the demanded vtable slot in the source 
interface . 

After execution of the dispatch call, the returned 
3 0 information is checked to determine whether a C++ 

exception was generated. If no exception has occurred, 
the inout/out parameters are reconverted. In this 
example, the reconversion of inout/out parameters is 
only important for values representing interfaces or 
3 5 values containing interfaces, because the values of all 
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objects in the UNO environment are binary compatible on 
a specific computing architecture. 

The UNO proxy, as defined by Table 9, holds the 
interface origin, i.e., the target C++ interface. 
5 Thus, the UNO proxy can register at with the UNO 

environment on the first execution of method acquire, 
and can revoke itself on its last execution of method 
release from its environment. 

The UNO proxy manages a reference count for the 

10 proxy, a pointer to the bridge of the UNO proxy to 

obtain the counterpart mapping, the C++ interface the 
UNO proxy delegates calls to, the (interface) type the 
UNO proxy is emulating, and an object identifier (oid) . 
The type and object identifier are needed to manage 

15 objects from environments, for proof of object 

identity, and to improve performance. A proxy to an 
interface is not needed if there is already a 
registered proxy for that interface. 

When the call to a method in the wrapped C++ 

20 interface is executed, the call is directed to the UNO 
proxy. Figure 11 is a process flow diagram of one 
embodiment of the operations performed by the UNO 
proxy. One example of computer code for this 
embodiment is presented in TABLE 16. 

25 

TABLE: 16. : EXAMPLE OF A METHOD dispatch USED BY A UNO 
PROXY WRAPPING A C++ INTERFACE 



void SAL_CALL cppu_unoInterf aceProxy_dispatch ( 
uno_Interf ace * pUnoI, const 

typelib_TypeDescription * pMemberDescr , void * 
pReturn, void * pArgs [] , uno_Any ** ppException ) 

{ 

// is my surrogate 

cppu_unoInterf aceProxy * pThis = static_cast< 
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cppu_unoInterf aceProxy * > ( pUnoI ) ; 
typelib_Interf aceTypeDescript ion * pTypeDescr = pThis- 
>pTypeDescr ; 

switch (pMeniberDescr->eTypeClass) 
{ 

case typel ib_TypeC las s_INTERFACE_ATTRIBUTE : 
{ 

// determine vtable call index 
sal_Int3 2 nMeraberPos = 

( (typelib_Interf aceMemberTypeDescription 

*) pMemberDescr) ->nPosition; 
OSL_ENSHURE ( nMeraberPos < pTypeDescr- >nAll Members , "### 

member pos out of range ! " ) ; 
sal_Int3 2 nVtableCall = pTypeDescr- 

>pMapMemberIndexToFunctionIndex [nMemberPos] ; 
OSL_ENSHURE( nVtableCall < pTypeDescr- 

>nMapFunctionIndexToMemberIndex, "### illegal 

vtable index!" ); 
typelib_TypeDescriptionRef erence * pRuntimeExcRef = 0; 
if (pReturn) 
{ 

// dependent dispatch 
cpp__call( pThis, nVtableCall, 

( ( typel ib_Interf aceAttributeTypeDescript ion 

* ) pMemberDescr) - >pAttributeTypeRef , 

0, 0, //no params 

1, &pRuntimeExcRef , // Runt imeExcept ion 
pReturn, pArgs, ppException ) ; 

} 

else 

{ 

//is SET 

typel ib_MethodParameter aParam; 
aParam. pTypeRef = 

( ( typel ib_Interf aceAtt ributeTypeDescript ion 
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* ) pMemberDescr ) - >pAttributeTypeRef ; 
aParara.bin = sal_True; 

aParam.bOut = sal_False; 

typelib_TypeDescriptionRef erence * pReturnTypeRef = 0; 
OUString aVoidName ( RTL_CONSTASCII_USTRINGPARAM ( "void" ) 
) ; 

Typelib_typedescriptionref erence_new (&pReturnTypeRef , 
typelib_TypeClass_VOID, aVoidName . pDat a ); 

/ / dependent dispatch 

cpp_call ( pThis, nVtableCall +1, // get, then set 
method 

pReturnTypeRef , 
1, &aParam, 
1, &pRuntimeExcRef , 
pReturn, pArgs, ppException ) ; 
typel ib_typede script ionref erence_re lease ( 
pReturnTypeRef ) ; 
} 

break; 
} 

case type 1 ib_Type C las s_INTERFACE_METHOD : 
{ 

/ / determine vtable call index 
sal_Int3 2 nMemberPos = 

( ( typel ib_Interf aceMemberTypeDescript ion 

*) pMemberDescr) ->nPosition; 
OSL_ENSHURE ( nMemberPos < pTypeDescr- >nAllMembers , "### 

member pos out of range ! " ) ; 
sal_Int32 nVtableCall = pTypeDescr- 

>pMapMemberIndexToFunctionIndex [nMemberPos] ; 
OSL_ENSHURE( nVtableCall < pTypeDescr- 

>nMapFunctionIndexToMember Index, "### illegal 

vtable index!" ); 
switch (nVtableCall) 
{ 
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// standard calls 

case 1: // acquire uno interface 
(*pUnoI->acquire) ( pUnoI ) ; 
*ppException = 0; 
break; 

case 2 : // release uno interface 
(*pUnoI->release) ( pUnoI ) ; 
*ppException = 0; 
break; 

case 0: // querylnterf ace () opt 
{ 

typelib_TypeDescription * pTD = 0; 

TYPELIB_DANGER_GET ( &pTD, reinterpret_cast< Type * >( 
pArgs [0] ) - >getTypeLibType () ) ; 

OSL_ASSERT ( pTD ) ; 

uno_Interf ace * plnterface = 0; 

( *pThis - >pBr idge - >pUnoEnv- 

>getRegisteredInterf ace) (pThis->pBridge- >pUnoEnv, 
(void **) &plnterf ace, pThis->oid.pData, 
(typelib_InterfaceTypeDescription *)pTD ); 

if (plnterface) 

{ 

uno_any_construct ( reinterpret_cast< uno_Any * > ( 

pReturn ) , &plnterface, pTD, 0 ) ; 
(*plnterface->release) ( plnterface ) ; 
TYPELIB_DANGER_RELEASE ( pTD ) ; 
*ppException = 0; 
break; 

} 

TYPELIB_DANGER_RELEASE ( pTD ) ; 

} // else perform querylnterf ace ( ) 

default : 

// dependent dispatch 
cpp_call ( pThis, nVtableCall, 

( (typelib_Interf aceMethodTypeDescription 

*) pMemberDescr) - >pReturnTypeRef , 
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( (typelib_Interf aceMethodTypeDescription 
*) pMemberDescr) ->nPararns, 

( (typelib_Int erf aceMethodTypeDescription 
*) pMemberDescr) ->pParams, 

( (typelib_Int erf aceMethodTypeDescription 
*) pMemberDescr) - >nExceptions , 

( (typelib_Int erf aceMethodTypeDescription 
*) pMemberDescr) ->ppExcept ions, pReturn, pArgs, 
ppException ) ; 
} 

break; 
} 

default : 
{ 

: .-com: :sun: : star : : uno : : Runt imeExcept ion aExc (OUString( 
RTL_CONSTASCII_USTRINGPARAM ( "illegal member type 
description!") ) , pThis - >pCppI ) ; 

typelib_TypeDescription * pTD = 0 ; 

const Type & rExcType = : :getCppuType ( (const 

: :com: : sun : :star: :uno: : Runt imeExcept ion *) 0 ) ; 

TYPELIB_DANGER_GET( &pTD, rExcType . getTypeLibType ( ) ); 

uno_any_construct ( *ppException, &aExc, pTD, 

0 ) ; 

TYPELI B_DANGER_RELEASE ( pTD ) ; 
} 
} 

} 



Method call check 1101 of method dispatch 1100 
determines whether the call is a method call. If the 
call is a method call processing transfers to 
5 acquire/release check operation 1110, and otherwise to 
attribute get check operation 1120. 
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Acquire/release check operation 1110 branches to 
acquire/release call operation 1111 if the method call 
is a call to either method acquire or method release, 
because these calls can be executed without calling the 
5 interface in the second environment. If the method 
call is not a call to either method acquire or method 
release, processing transfers from check operation 1110 
to query interface check operation 1112 . 
Acquire/Release call operation 1111 performs the 
10 appropriate method, which is a non-virtual call, and 
returns . 

Query interface check operation 1112 determines 
whether the method call is to method querylnterf ace . 
If the method call is not to method querylnterf ace , 

15 check operation 1112 transfers to call Env2_to_Envl 

with Interface operation 113 0 and otherwise transfers 
to registered interface available check operation 1113. 

If there is a registered interface in the source 
environment for method querylnterf ace , check 

20 operation 1113 transfers to set return value 

operation 1114 and otherwise to call Env2_to_Envl with 
Interface operation 1130. Set return value 
operation 1114 sets the registered interface as the 
return value and returns . 

25 If the call to the C++ proxy was not a method 

call, check operation 1101 transfers to attribute get 
check operation 1120. In this embodiment, there is 
either an attribute get or an attribute set. If the 
call to the UNO proxy is an attribute get, check 

30 operation 1120 transfers to prepare attribute get call 
operation 1121 and otherwise transfers to prepare 
attribute set call operation 1122. Both 
operations 1121 and 1122 set up the parameters for the 
call and transfer to call Env2_to_Envl with Interface 

35 operation 1130. The call is given the C++ interface 
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pointer, a vtable index, and all parameters necessary 
to perform the C++ virtual function call. 

An embodiment of method Env2_to_Envl with 
interface for the UNO proxy is presented in Table 17. 
5 Figure 12 is a process flow diagram for one embodiment 
of method Env2_to_Envl with interface. 

TABLE 17.: EXAMPLE of METHOD Env2_to_Envl with 
interface FOR THE UNO PROXY 

10 



namespace CPPU_CURRENT_NAME SPACE 
{ 

inline static void cpp_call (cppu_unoInt erf ace Proxy * 
pThis, sal_Int32 nVtableCall, 

typelib_TypeDescriptionRef erence * pReturnTypeRef , 
sal_Int32 nParams, typelib_MethodParameter * 
pParams, sal_Int32 nExceptions, 
typelib_TypeDescriptionRef erence ** 
ppExceptionRef s, void * pUnoReturn, void * 
pUnoArgs [] , uno_Any ** ppUnoExc ) 

{ 

// max space for: [complex ret ptr] , values jptr ... 
char * pCppStack = (char *)alloca( sizeof (sal_Int32 ) + 

(nParams * sizeof (sal_Int64) ) ) ; 
char * pCppStackStart = pCppStack ; 
// return 

typelib_TypeDescription * pReturnTypeDescr = 0; 
TYPELIB_DANGER_GET ( &pReturnTypeDescr , pReturnTypeRef 
) ; 

OSL_ENSHURE( pReturnTypeDescr, "### expected return 

type description!" ); 
// if != 0 ScSc != pUnoReturn, needs reconversion 
void * pCppReturn = 0 ; 
if (pReturnTypeDescr) 
{ 



-74- 



AsFiled 
P-4355 



if (cppu_isSimpleType ( pReturnTypeDescr )) 
{ 

pCppReturn = pUnoReturn; // direct way for simple types 
} 

else 
{ 

// complex return via ptr 
// direct way 

pCppReturn = * (void **)pCppStack = 

(cppu_relatesToInterface ( pReturnTypeDescr ) ? 

alloca( pReturnTypeDescr- >nSize ) : pUnoReturn); 
pCppStack += sizeof(void *) ; 
} 
} 

// stack space 

OSL_ENSHURE( sizeof (void *) == sizeof (sal_Int32 ) , "### 

unexpected size!" ) ; 
// args 

void ** pCppArgs = (void **)alloca( 3 * sizeof (void *) 
* nParams ) ; 

// indices of values thats have to be converted 
// (interface conversion cpp<=>uno) 

sal_Int32 * pTempIndizes = (sal_Int32 *) (pCppArgs + 
nParams) ; 

// type descriptions for reconversions 

type lib_TypeDescript ion ** ppTempParamTypeDescr = 

(typelib_TypeDescription **) (pCppArgs + (2 * 

nParams) ) ; 
sal_Int32 nTempIndizes = 0; 

for ( sal_Int32 nPos = 0; nPos < nParams; ++nPos ) 
{ 

const typelib_MethodParameter & rParam = pParams [nPos] ; 
typelib_TypeDescription * pParamTypeDescr = 0; 
TYPELIB_DANGER_GET ( &pParamTypeDescr , rParam.pTypeRef 
) ; 

if ( IrParam.bOut && cppu_isSimpleType ( pParamTypeDescr 
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) ) 

{ 

uno_copyAndConvertData ( pCppArgs [nPos] = pCppStack, 

pUnoArgs [nPos] , pParamTypeDescr , &pThis- >pBridge- 
>aUno2Cpp ) ; 

switch (pParamTypeDescr- >eTypeClass) 

{ 

case typelib_TypeClass_HYPER: 

case typelib_TypeClass_UNSIGNED_HYPER : 

case typelib_TypeClass_DOUBLE : 

pCppStack += sizeof (sal_Int32) ; // extra long 
} 

//no longer needed 

TYPELIB_DANGER_RELEASE ( pParamTypeDescr ) ; 
} 

else // ptr to complex value | ref 
{ 

if (! rParam.bin) // is pure out 
{ 

// cpp out is constructed mem, uno out is not I 
uno_constructData ( * (void **) pCppStack = 

pCppArgs [nPos] = alloca{ pParamTypeDescr- >nSize ) 

pParamTypeDescr ) ; 
pTempIndizes [nTempIndizes] = nPos; 
// default constructed for cpp call 
// will be released at reconversion 

ppTempParamTypeDescr [nTempIndizes++] = pParamTypeDescr 
} 

// is in/inout 

else if (cppu_relatesToInterface ( pParamTypeDescr )) 
{ 

uno_copyAndConvertData ( * (void **) pCppStack = 

pCppArgs [nPos] = alloca( pParamTypeDescr- >nSize ) 
pUnoArgs [nPos] , pParamTypeDescr, &pThis- >pBridge 
>aUno2Cpp ) ; 

pTempIndizes [nTempIndizes] = nPos ; 
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// has to be reconverted 

// will be released at reconversion 

ppTempParamTypeDescr [nTempIndizes++] = pParamTypeDescr ; 
} 

else // direct way 
{ 

* (void **) pCppStack = pCppArgs [nPos] = pUnoArgs [nPos] ; 
//no longer needed 

TYPEL I B_DANGER_RELEAS E ( pParamTypeDescr ) ; 

} 

} 

pCppStack += sizeof (sal_Int32) ; // standard parameter 
length 

} 

// only try-finally/ try-except statements possible... 

try 

{ 

try 

{ 

// pCppI is msci this pointer 

callVirtualMethod( pThis- >pCppI , nVtableCall, 
pCppReturn, pReturnTypeDescr- >eTypeClass , 
(sal_Int32 * ) pCppStackStart , (pCppStack - 
pCppStackStart) / sizeof (sal_Int32 ) ) ; 

// NO exception occured. . . 

*ppUnoExc = 0; 

// reconvert temporary params 

while (nTempIndizes- - ) 

{ 

sal_Int32 nlndex = pTempIndizes [nTempIndizes] ; 
typelib_TypeDescription * pParamTypeDescr = 

ppTempParamTypeDescr [nTempIndizes] ; 
if (pParams [nlndex] .bin) 
{ 

if (pParams [nlndex] .bOut) // inout 
{ 

-77- 



AsFiled 
P-4355 



uno_destructData ( pUnoArgs [nlndex] , pParamTypeDescr , 0 

) ; // destroy uno value 
uno_copyAndConvertData ( pUnoArgs [nlndex] , 

pCppArgs [nlndex] , pParamTypeDescr, SpThis- 

>pBridge->aCpp2Uno ) ; 

} 
} 

else // pure out 
{ 

uno_copyAndConvertData ( pUnoArgs [nlndex] , 

pCppArgs [nlndex] , pParamTypeDescr, &pThis- 
>pBridge->aCpp2Uno ) ; 

} 

// destroy temp cpp param => cpp : every param was 
// constructed 

uno_destructData ( pCppArgs [nlndex] , pParamTypeDescr, 

cpp_release ) ,- 
TYPELIB_DANGER_RELEASE ( pParamTypeDescr ) ; 

} 

// return value 

if {pCppReturn && pUnoReturn != pCppReturn) 
{ 

uno_copyAndConvertData ( pUnoReturn, pCppReturn, 

pReturnTypeDescr , 
&pThis->pBridge->aCpp2Uno ) ; 

uno_destructData ( pCppReturn, pReturnTypeDescr, 
cpp_release ) ; 

} 
} 

except (msci_f ilterCppExcept ion ( 

GetExceptionlnformationO , *ppUnoExc, &pThis- 
>pBridge->aCpp2Uno )) 

{ 

// *ppUnoExc is untouched and any was constructed by 

// filter function finally block will be called 

return; 
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} 
} 

finally 

{ 

// cleanup of params was already done in reconversion 
// loop if no exception occured; this is quicker than 
// getting all param descriptions twice! so cleanup 
// only if an exception occured: 
if (*ppUnoExc) 
{ 

// temporary params 
while (nTempIndizes--) 
{ 

sal_Int32 nlndex = pTempIndizes [nTempIndizes] ; 

// destroy temp cpp param => cpp : every param was 

// constructed 

uno_destructData ( pCppArgs [nlndex] , 

ppTempParamTypeDescr [nTempIndizes] , cpp_release ) ; 
TYPEL I B_DANGER_RELEASE ( 

ppTempParamTypeDescr [nTempIndizes] ) ; 

} 
} 

// return type 

if (pReturnTypeDescr) 

TYPELIB_DANGER_RELEASE ( pReturnTypeDescr ) ; 

} 

} 



In Figure 12, read parameters operation 1201 reads 
the parameters from the call. Read parameters 
operation 12 01 transfers to convert parameters 
5 operation 1202. Convert parameters operation 1202 

converts the parameters read to the C++ environment . A 
C++ call stack is built in memory. All simple types, 
up to eight bytes are put directly on the stack, and 
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all other types are referenced by a pointer. 
Operation 12 02 transfers to allocate memory 
operation 1203. Allocate memory operation 1203 
allocates memory for the out parameters returned by the 
5 call to the C++ interface, and for the return value. 
Allocate memory operation 1203 transfers processing to 
dispatch call operation 1204. 

Dispatch call operation 12 04 performs a C++ 
virtual call on the C++ interface. In one embodiment, 

10 method callVirtual, an assembly function performing the 
specific virtual call having the right registers set 
(See Table 18) , is called and passed an array that is 
the call stack. The call is executed in the C++ 
environment and the results, if any, are returned to 

15 operation 1204 that in turn transfers to exception 
check operation 1205. 

Exception check operation 12 05 determines whether 
an exception was thrown in response to the call. If an 
exception was thrown, check operation 1205 transfers 

2 0 processing to convert exception operation 1210 and 
otherwise processing transfers to set exception 
operation 1220. 

Convert exception operation 1210 converts the C++ 
exception to the UNO environment, and sets an exception 

25 out any with the converted exception. Operation 1210 
transfers to clean up operation 1211 that in turn 
cleans up any temporary parameters that were created in 
the call in operation 1204 and transfers to return to 
operation 1130. 

30 If an exception was not thrown in the source 

environment, set exception operation 122 0 sets the 
exception out any to zero, and transfers to convert 
parameters operation 1221. 

Convert parameters operation 1221 converts any 

35 parameters that were returned from operation 12 04, 

e.g., out parameters and/or inout parameters, from the 
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source environment, i.e., the C++ environment, to the 
destination environment, i.e., the UNO environment. 
Operation 1221 also cleans up any temporary parameters 
that were created in the call in operation 12 04 and 
5 transfers to convert return value operation 1222. 
Operation 1222 converts any return value from the 
source environment to the destination environment so 
that both the return value and any returned parameters 
are written back, in this example to the UNO caller. 



TABLE 18. : AN EXAMPLE OF A METHOD 
callVirtualMethod THAT IS USED BY THE UNO PROXY TO 
DISPATCH A CALL TO THE INTERFACE IN THE C++ ENVIRONMENT 



inline static void callVirtualMethod ( void * pThis, 
sal_Int32 nVtablelndex, void * pRegisterReturn, 
typelib_TypeClass eReturnTypeClass , sal_Int32 * 
pStackLongs, sal_Int32 nStackLongs ) 
{ 

// parameter list is mixed list of * and values 
// reference parameters are pointers 

OSL_ENSHURE( pStackLongs && pThis, "### null ptr!" ) ; 
OSL_ENSHURE ( (sizeof (void *) ==4) && 

(sizeof (sal_Int32) == 4), "### unexpected size of int ! " 



10 



asm 



{ 



mov 



eax, nStackLongs 



test 



eax, eax 



je 

/ / copy values 



Lcall 



mov 



ecx, eax 



add 



shl 



eax, 2 // sizeof (sal_Int32) == 4 

eax, pStackLongs // params stack space 



Lcopy : 



sub 



eax, 4 



-81- 



AsFiled 
P-4355 



push 
dec 
jne 
Lcall : 
// call 
mov 
push 
mov 
mov 
shl 
add 



dword ptr [eax] 

ecx 

Lcopy 



ecx, pThis 

ecx // this ptr 

edx, [ecx] // pvft 

eax, nVtablelndex 

eax, 2 // sizeof (void *) 

edx, eax 

call [edx] //interface method call must be 
// register return 



mov 
cmp 
je 
mov 
// int32 
cmp 
je 
cmp 
je 
cmp 
je 

// int8 
cmp 
je 
cmp 
je 

// intl6 
cmp 
je 
cmp 
je 
cmp 
je 



ecx, eReturnTypeClass 

ecx, typelib_TypeClass_VOID 

Lcleanup 

ebx, pRegisterReturn 

ecx, typelib_TypeClass_LONG 
Lint32 

e cx , type 1 i b_TypeC 1 a s s_UNS I GNED_LONG 
Lint32 

ecx, typelib_TypeClass_ENUM 
Lint32 

ecx, typelib_TypeClass_BOOLEAN 
Lint8 

ecx, typelib_TypeClass_BYTE 
Lint 8 

ecx, typelib_TypeClass_CHAR 
Lintl6 

ecx, typelib_TypeClass_SHORT 
Lint 16 

ecx, typeli b_Typ e C 1 a s s_UNS I GNED_S HORT 
Lintl6 
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// float 

cmp ecx, typelib_TypeClass_FLOAT 

je Lfloat 
// double 

cmp ecx, typelib_TypeClass_DOUBLE 

je Ldouble 
// int64 

cmp ecx, typelib_TypeClass_HYPER 

je Lint64 

cmp ecx, typelib_TypeClass_UNSIGNED_HYPER 

je Lint64 



jmp Lcleanup //no simple type 
Lint8 : 

mov byte ptr [ebx] , al 

jmp Lcleanup 
Lint 16 : 

mov word ptr [ebx] , ax 

jmp Lcleanup 
Lfloat: 

fstp dword ptr [ebx] 

jmp Lcleanup 
Ldouble : 

fstp qword ptr [ebx] 

jmp Lcleanup 
Lint64 : 

mov dword ptr [ebx] , eax 

mov dword ptr [ebx+4] , edx 

jmp Lcleanup 
Lint32 : 

mov dword ptr [ebx] , eax 

jmp Lcleanup 
Lcleanup: 

// cleanup stack (obsolete though because of function) 
mov eax, nStackLongs 

shl eax, 2// sizeof (sal_Int32 ) == 4 

add eax, 4 // this ptr 
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add esp, eax 




In the above description of the example, various 
methods were described and discussed. Figure 13A to 24 
are specific examples of one embodiment of such 
methods. In particular, in Figs 13A and 13B, an 
embodiment of mapping an interface from the UNO 
environment to the C++ environment is presented. See 
Figure 4 . 

Fig. 14 is an example of a method free and a 
method for revoking the proxy. Method free is called 
indirectly by the C++ proxy described above when the 
reference count goes to zero and the C++ proxy should 
be deleted. Fig. 15 includes an example of a C++ proxy 
that includes a method acquireProxy ; an example of a 
method releaseProxy that is used to revoke the C++ 
proxy from the C++ environment structure; and a method 
ccpu_cpplnterf aceProxy to instantiate, acquire and 
register the C++ proxy. 

Figs. 16A and 16B include an example of a method 
free that is called indirectly by the UNO proxy 
described above when the reference count goes to zero 
and the UNO proxy should be deleted; an example of a 
method acquire that is used in acquiring the UNO proxy; 
and an example of a method release that is used to 
revoke the UNO proxy. 

In Figs 17A and 17B, an embodiment of a method 
Mapping for mapping from the C++ environment to the UNO 
environment is presented. Figure 18 includes is a C++ 
implementation of the UNO proxy that includes a 
constructor cpu_unoInterf aceProxy to instantiate, 
acquire and register the UNO proxy; a method for 
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acquiring a mapping and a method for releasing a 
mapping . 

Figure 19 illustrates constructors for a mapping 
and a bridge; and a method for freeing a bridge. 
5 Figure 2 0 is an embodiment of methods for acquiring and 
releasing a bridge. Figure 21 includes a method 
cppu_ext_getMapping to create a mapping between two 
specified environments. Figure 22 is an embodiment of 
a method to create the static part of an object Id. 

10 The object id contains two parts, an object specific 

part and a static part. Figure 23 is an embodiment of 
a method to create a complete object Id, containing 
both, the object specific and the static parts. 
Figure 24 includes a method for acquiring a C++-uno 

15 environment; a method for releasing a C++-uno 

environment; and a method to initialize a C++-uno 
environment . 



